Tracking Lockfiles With git-lfs
Avoid deceptively large pull requests by tracking your package-lock.json or yarn.lock file using git-lfs.
We’ve all seen one of these:
On closer inspection it’s revealed that the pull request is simply a minor feature update, with a couple of new packages with large dependency trees. Almost all of the additional lines occur in a lockfile (e.g. package-lock.json or yarn.lock depending on your choice of package manager).
This becomes a particular nuisance when pull requests are filtered and tagged by size, and code reviews for simple PRs may be deferred as a result.
Fortunately git-lfs provides a simple solution. Essentially git-lfs allows you to tag specific files which are tracked as pointers containing a hash of the file contents. The files are stored independently of the repository and don’t affect the size of pull requests. There is no affect on the git workflow — cloning, editing, viewing and commiting files can be executed as normal. git-lfs is supported by all major git cloud hosts (i.e. GitHub, Bitbucket and GitLab).
Visit https://git-lfs.github.com/ for installation and setup instructions. Once git-lfs is installed, you will want to run git lfs track package-lock.json in your project root to track your lockfile.
Considerations
Changes to files tracked with git-lfs won’t be displayed in pull requests. If you have a strict manual dependency auditing process as part of your code review procedure then this may not be appropriate for your workflow.
And I discovered this one the hard way — If you are running npm install in your CI/CD pipeline you will need to make sure that LFS files are downloaded. For instance, in GitHub actions, the checkout action does not download LFS files by default. The following settings are required to set this right:
- uses: actions/checkout@master
with:
lfs: true