Skip to content
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

Merged
merged 1 commit into from
Oct 3, 2022

Conversation

jurre
Copy link
Member

@jurre jurre commented Oct 3, 2022

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 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.
@jurre jurre requested a review from a team as a code owner October 3, 2022 11:52
"yarn remove #{dep.name}"
"yarn add #{update} --mode=update-lockfile",
"yarn dedupe #{dep.name} --mode=update-lockfile",
"yarn remove #{dep.name} --mode=update-lockfile"
Copy link
Member Author

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.

Copy link
Contributor

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 👍🏻

@jurre
Copy link
Member Author

jurre commented Oct 3, 2022

On a large-ish repo:

time yarn add @actions/[email protected]
yarn add @actions/[email protected]  9.02s user 3.63s system 51% cpu 24.357 total

vs

time yarn add @actions/[email protected] --mode=update-lockfile
yarn add @actions/[email protected] --mode=update-lockfile  2.50s user 0.25s system 74% cpu 3.674 total

Another option could be to detect if there is a yarn cache folder present, and if there is not, then we use the update-lockfile mode. From the logs it does appear that the most costly step is fetching all the missing packages, which we would not have to do when there is a cache folder committed to the repo.

"yarn remove #{dep.name}"
"yarn add #{update} --mode=update-lockfile",
"yarn dedupe #{dep.name} --mode=update-lockfile",
"yarn remove #{dep.name} --mode=update-lockfile"
Copy link
Contributor

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 👍🏻

@brrygrdn
Copy link
Contributor

brrygrdn commented Oct 3, 2022

Another option could be to detect if there is a yarn cache folder present, and if there is not, then we use the update-lockfile mode.

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 🤔

@jurre
Copy link
Member Author

jurre commented Oct 3, 2022

Another option could be to detect if there is a yarn cache folder present, and if there is not, then we use the update-lockfile mode.

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:

Starting from Yarn v2, Yarn will by default configure the cache to be local to your project. This is done to make it easier for you to store it as part of your repository, which we believe is the best way to ensure that your projects can still be installed just fine regardless of the availability of your package registries.

I don't have any numbers, but anecdotally I've seen more repo's that don't have it in version control

@jurre jurre merged commit ed74216 into main Oct 3, 2022
@jurre jurre deleted the jurre/yarn-berry-update-lockfile-mode branch October 3, 2022 15:41
@jurre jurre mentioned this pull request Oct 5, 2022
@pavera pavera mentioned this pull request Oct 31, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants