Repository navigation
Use Yarn 4 RC on our CI - #109
Conversation
|
I’m confused; if it’s stable why is it still an RC? node ships corepack now, and node shouldn’t ship RCs. |
I admit the PR title is a little confusing - this PR doesn't change anything to what Corepack distributes (that's what #106 is for). It simply changes the package manager version used to develop on this very repository. |
| corepack yarn --immutable --immutable-cache --check-cache | ||
| if: | | ||
| github.event.pull_request != '' | ||
| - run: corepack yarn install |
There was a problem hiding this comment.
Non-blocking suggestion: IIUC, those flags are implicitly enable when Yarn 4 is run from a CI env, correct? While I agree it's a nice default, Iimo it's still worth explicitly adding the files so a human can run the command by copy pasting without needing to learn Yarn's defaults.
| - run: corepack yarn install | |
| - run: corepack yarn install --immutable --refresh-lockfile |
There was a problem hiding this comment.
Yep, --immutable is always on by default on CI; the --refresh-lockfile and --check-resolutions flags are only enabled on PRs (given that they don't run on other branches, making them explicit would impact performances)
There was a problem hiding this comment.
Makes sense. We could add a comment explaining that.
| node-version: ${{matrix.node}}.x | ||
|
|
||
| - run: corepack yarn install --immutable | ||
| - run: corepack yarn install |
There was a problem hiding this comment.
Is this necessary if the previous job has already run the necessary checks?
| - run: corepack yarn install |
There was a problem hiding this comment.
Since the chore and ci jobs execute in parallel, both need to run an install (it wasn't the case before because the cache was checked-in).
There was a problem hiding this comment.
Ah gotcha I thought we were still on zero-install.
Co-authored-by: Kristoffer K. <merceyz@users.noreply.github.com>
The Yarn releases are quite stable, even RCs, so I'd like to stay up-to-date when possible. It also guards against some lockfile injection attacks.
One major change is that the checked-in cache is now disabled by default since it's only needed in specific situation (typically repositories with large amount of contributions per day); Corepack not being one, I didn't re-enable it in the configuration.