Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Speed up
npm ci
by cachingnode_modules
#45932Speed up
npm ci
by cachingnode_modules
#45932Changes from 6 commits
f4ec7b3
239050c
2eff8c8
38bca97
4014266
65efe55
1c9ca27
e437750
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
I'm thinking that we don't need to include the npm version in the cache key here.
I can't think of a scenario where the version of npm would change independent of the Node.js version.
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.
doesn't this happen regularly in Gutenberg since our
npm
version is still gated at<7
?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.
I don't think we need to include
npm
version here too. Including it will potentially bust the cache more often.That's because we're using Node 14, which comes with npm v6 by default. npm versions could change independently from Node.js, but they should just be minor releases and backward-compatible.
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.
When a new version of Node.js is released, a specific version of npm is bundled with that version. You'll find an all inclusive manifest here. As long ass the
npm install -g npm
command is not run, then the version originally bundled with that version of Node.js will be the one installed.I looked through the code of actions/setup-node. While I wasn't able to confirm this 100%, it seems that new version are pulled and built for use within Action runners using this manifest through the actions/node-versions and actions/versions-package-tools.
Because we only install Node 14.x, the version of npm will always be
< 7
, but the specific version of npm6.x
installed will be tied to the specific version of Node installed.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.
Right, but according to the project's
package.json
file we're good to usenode@latest
, which is I think what most people end up doing locally.gutenberg/package.json
Lines 17 to 20 in 6434e0b
so maybe by happenstance we're only using
node@14
in the test suites, but even then, are we guaranteed to run the specific version of 14? or are we pinning it entirely at a specific version?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.
.nvmrc
pins the Node.js version to 14 on CI. FWIW, there's an ongoing PR (#48950) that hopefully can be merged soon to upgrade Node.js and npm to latest on CI.Nope, if there's a minor/patch release then we'll automatically use the newer version on CI (basically
^14
). But that's okay since we include the full node version in the cache key.Note that this PR doesn't affect anyone's local setup whatsoever, they can continue using whatever supported Node.js/npm version they like locally. And the cache only exists on CI, so they won't be affected by it either. This PR only caches
node_modules
on CI, which is a controlled environment.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.
I think we're in agreement here. my comment was specifically commenting on how we do expect changes to
node
to occur that don't matchnpm
. we're intentionally not using the bundled version ofnpm
in the project, but we build the project with changing versions ofnode
quite often, since we pinnode
at>=
a major version.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.
What's the difference between running
postinstall
fornpm
andnpx lerna
? Do we need both?If so, I'm wondering if we should split into two steps. That would make it more clear which of the two fails should either encounter a problem.
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.
I added some comments explaining this ❤️ .
I don't think we need to split it into two steps though, as they have the same goal.
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.
We're running
npm run build
, but it's not just an npm build. Maybe "Run build scripts" would be more general and accurate. If we change this, it should get changed everywhere.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, let's do this in another PR though.
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.
Hmm, this seems to be running the Lerna build script.
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.
"Build Lerna" isn't really descriptive either though. I think this should be "Build packages" and just run
npm run build:packages
. But it's already the way it is in trunk, so maybe we should change it in another PR?