docs: Change Node.js npm dependencies install in caching example
What does this MR do?
Hello, this is a proposition about changing the documentation CI cache example for Node.js dependencies to use npm ci
instead of npm install
npm ci
The documentation of npm ci
can be found here, it’s meant to be used in automated environments to get a clean state. It's faster and doesn't change the package.json file like npm install
does so we can have reproducible build. I think it's important to use good practices in documentation and examples.
Caching
We can't cache the node_modules folder because:
If a node_modules is already present, it will be automatically removed before npm ci begins its install.
What we need to do is caching the npm cache folder.
The default location is $HOME/.npm
but since we can't cache things outside of the project directory we have to specify npm to use the ./.npm
folder instead.
We do that with the --cache .npm
see npm cache config doc
We also use the --prefer-offline
see npm prefer-offline doc (I'm not sure about this one because I've had hard time finding out documentation about what they call staleness checks so maybe if someone can check ?)
Note: A similar thing has been done for caching the Maven $HOME/.m2
in an example of the doc
About Yarn
I've remove the mention to Yarn because the command is different. Yarn use yarn.lock
instead of package-lock.json
. We would have to use yarn install --frozen-lockfile --cache-folder .yarn-cache --prefer-offline
and cache the .yarn-cache
folder like it's done in the GitLab CI of Gitlab. I didn't want to add too many things to the example.
Thanks
They are others place in the doc or in the templates where we might do this change as well, I'd be happy to contribute if you're interested
So tell me what you think. Is it a good or a bad idea ? Do I need to change something ?
Related issues
Author's checklist
-
Follow the Documentation Guidelines and Style Guide. -
If applicable, update the permissions table. -
Link docs to and from the higher-level index page, plus other related docs where helpful. -
Apply the documentation label.
Review checklist
All reviewers can help ensure accuracy, clarity, completeness, and adherence to the Documentation Guidelines and Style Guide.
1. Primary Reviewer
-
Review by a code reviewer or other selected colleague to confirm accuracy, clarity, and completeness. This can be skipped for minor fixes without substantive content changes.
2. Technical Writer
-
Optional: Technical writer review. If not requested for this MR, must be scheduled post-merge. To request for this MR, assign the writer listed for the applicable DevOps stage.
3. Maintainer
-
Review by assigned maintainer, who can always request/require the above reviews. Maintainer's review can occur before or after a technical writer review. -
Ensure a release milestone is set. -
If there has not been a technical writer review, create an issue for one using the Doc Review template.