Use CI friendly commands in documentation

[jonkoops]

Replaces npm install with npm ci command and adds the --frozen-lockfile flag for Yarn and PNPM installation commands. This makes installation of packages faster (for NPM) and provides guarantees about lockfile correctness at install time.

Previous efforts for this are documented in #103.

[privatenumber]

@dmitry-shibanov Anything blocking this from getting merged?

[pi9min]

+1

[hubgit]

Does it make sense to use npm ci when the dependencies are being restored from a cache?

[jonkoops]

I believe the cache option only caches the global cache, not the node_modules directory. So it still makes sense.

[hubgit]

It does look like it's running npm config get cache to get the path to cache, so that does make sense, thanks 👍

[jonkoops]

@dmitry-shibanov @brcrista @marko-zivic-93 is there any interest in getting this merged?

[dmitry-shibanov]

Hello @jonkoops. Thank you for your pull request. I think we can adjust these changes when caching is enabled, because it relies on hash from dependency files. For other cases I think we should leave it as npm install because some repositories do not have package-lock.json.

[jonkoops]

For other cases I think we should leave it as npm install because some repositories do not have package-lock.json.

I think differently about this matter, checking in lockfiles is considered best practice for all package managers. Instead of appeasing users that might not have checked this file in we should encourage them to follow these practices.

For example, the NPM documentation says the following about the package-lock.json file:

This file is intended to be committed into source repositories, and serves various purposes:

• Describe a single representation of a dependency tree such that teammates, deployments, and continuous integration are guaranteed to install exactly the same dependencies.
• Provide a facility for users to "time-travel" to previous states of node_modules without having to commit the directory itself.
• Facilitate greater visibility of tree changes through readable source control diffs.
• Optimize the installation process by allowing npm to skip repeated metadata resolutions for previously-installed packages.
• As of npm v7, lockfiles include enough information to gain a complete picture of the package tree, reducing the need to read package.json files, and allowing for significant performance improvements.

All of these points apply directly to Github and Github Actions and I believe that these best practices should be reflected here as well.

I propose that all commands are replaced with their appropriate CI friendly versions as per the original purpose of this PR and that the documentation is amended to have a dedicated section to lockfiles.

[jonkoops]

I've added some documentation about lockfiles as mentioned above.

[privatenumber]

For an official action like this, I think it's important to use examples that adopt best practices.

There are many beginners that read these examples that are not aware of the trade-offs between npm install and npm ci.

The problem with using npm install or not using package-lock.json is that there's a chance their CI will unexpectedly fail because of inconsistent dependencies.

For example, a new dependency update that satisfies the package.json semver range can be installed on the CI before the developer tests it locally and fail (or even worse, fail silently and trigger a release).

npm ci was designed for Continuous Integration to prevent these problems.

[dmitry-shibanov]

Thank you @jonkoops for improving the documentation and your work.

[jonkoops]

Thanks for taking this into consideration and merging it!