Skip to content

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

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

  1. Review by assigned maintainer, who can always request/require the above reviews. Maintainer's review can occur before or after a technical writer review.
  2. Ensure a release milestone is set.
  3. If there has not been a technical writer review, create an issue for one using the Doc Review template.
Edited by Marcel Amirault

Merge request reports