-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Yarn Berry: Run commands in update-lockfile
mode
#5827
Conversation
Yarn Berry commands related to performing updates can run in a mode called `update-lockfile`, which was purpose-built for exactly what Dependabot does: ``` - `update-lockfile` will skip the link step altogether, and only fetch packages that are missing from the lockfile (or that have no associated checksums). This mode is typically used by tools like Renovate or Dependabot to keep a lockfile up-to-date without incurring the full install cost. ``` This makes yarn berry updates _significantly_ more performant, but it has the downside that when the yarn cache is committed to the repo, old entries in there are not cleaned up. Everything still works as expected when this happens, but over time it could lead to that cache folder getting larger than is necessary. I've opened an issue about this upstream: yarnpkg/berry#4886, not entirely sure if this is a bug or just a consequence of how this works. For now I think it's worth the trade-off, as many projects don't commit the cache folder to repo, and the performance benefits are very significant. I'll try to find some time to address this upstream.
"yarn remove #{dep.name}" | ||
"yarn add #{update} --mode=update-lockfile", | ||
"yarn dedupe #{dep.name} --mode=update-lockfile", | ||
"yarn remove #{dep.name} --mode=update-lockfile" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Opted to pass the argument vs automatically adding it in run_yarn_commands
, since not all commands take that option and I figured it would lead to confusing errors down the line when using run_yarn_commands
with one of those commands.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, this seems like the right trade-off 👍🏻
On a large-ish repo:
vs
Another option could be to detect if there is a yarn cache folder present, and if there is not, then we use the |
"yarn remove #{dep.name}" | ||
"yarn add #{update} --mode=update-lockfile", | ||
"yarn dedupe #{dep.name} --mode=update-lockfile", | ||
"yarn remove #{dep.name} --mode=update-lockfile" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, this seems like the right trade-off 👍🏻
I like this idea, I'm not sure we need to block on adding this since we are in beta and as you say, committing the cache is potentially not something many projects do 🤔 |
It is recommended by yarn:
I don't have any numbers, but anecdotally I've seen more repo's that don't have it in version control |
Yarn Berry commands related to performing updates can run in a mode called
update-lockfile
, which was purpose-built for exactly what Dependabot does:This makes yarn berry updates significantly more performant, but it has the downside that when the yarn cache is committed to the repo, old entries in there are not cleaned up. Everything still works as expected when this happens, but over time it could lead to that cache folder getting larger than is necessary.
I've opened an issue about this upstream:
yarnpkg/berry#4886, not entirely sure if this is a bug or just a consequence of how this works.
For now I think it's worth the trade-off, as many projects don't commit the cache folder to repo, and the performance benefits are very significant.
I'll try to find some time to address this upstream.