yarn_install should use --frozen-lockfile

[adam-azarchs]

🚀 feature request

Relevant Rules

yarn_install, npm_install

Description

In the interest of build reproduciblity, if the lockfile is wrong or incomplete then the build should fail. Running in these frozen modes is often faster as well.

Describe the solution you'd like

• yarn_install should use yarn install --frozen-lockfile
• npm_install should use npm ci instead of npm install

This is of course assuming that the relevant tools are new enough to support those arguments.

• npm added the ci option in 5.7.1. The first node release to ship with npm>5.5.1 was 8.12.0, which could be an issue for versions 8.11.1 or 8.9.1. which are still supported by the rules.
• yarn has had the --frozen-lockfile parameter since v0.19.0 - much older than any of the supported versions.

Describe alternatives you've considered

Make it optional? Doesn't seem like a good idea, though.

[Globegitter]

My workflow is usually to add a package to the package.json or update it there and then let bazel handle the regeneration of my lock file. So if this was not customizable this imo valid workflow would break.

[adam-azarchs]

While it wouldn't be how I'd do things, I can see an argument for it. However in the context of for example a CI system, it seems not unreasonable to demand that the lock file is frozen. That's what lock files are for, after all.

[Globegitter]

Yep I do agree in a CI system it makes total sense and I would also be very happy to have it there. I was thinking in general if there is some way we can clean up the attributes for the flags a bit. There is one to add prod_only, one to switch to a local cache via use_global_yarn_cache and one to configure network_timeout and now this would add a fourth attribute and who knows, in the future there might be further ones coming.

Maybe we could just get rid of all of those before 1.0 and have a generic args attribute or extra_args, so the user can pass in whatever flags they want. The only tricky thing is that we use --cwd, --network-timeout, and --mutex per default, so we would need some validation, e.g. cwd should not be overriden, --network-timeout we could probably just override if that is provided but --mutex would need a bit more thinking. So yeah I wonder if we can do this in some nice way. WDYT?

But even if we have it configurable the question is what should be the default and if we should make it configurable on a per-invocation basis. Unfortunately currently bazel only allows that via env vars for repository rules. So we could check for a BAZEL_YARN_FROZEN_LOCKFILE env var or similar to set the flag dynamically.

[github-actions]

This issue has been automatically marked as stale because it has not had any activity for 60 days. It will be closed if no further activity occurs in two weeks. Collaborators can add a "cleanup" or "need: discussion" label to keep it open indefinitely. Thanks for your contributions to rules_nodejs!

[DavidANeil]

This can be done through passing args = ["--frozen-lockfile"], to the yarn_install in your WORKSPACE file.

[alexeagle]

#2327 fixed it