[Feature] v2 equivalent of v1's "yarn install --production --frozen-lockfile"

• I’d be willing to implement this feature (contributing guide)
• This feature is important to have in this repository; a contrib plugin wouldn’t do

---

User Story

As a developer who ships several Node.js-based Docker images, Yarn v1 has historically offered me two important functionalities in my workflows:

• yarn install --production[=true]: Optimized final runtime image sizes via installing only production dependencies (as devDependencies were simply unused/unnecessary to ship).

• yarn install --frozen-lockfile: Determinism is required in the Docker builds - a build today should be exactly the same as a build a year from now (barring timestamp differences). The v1 --frozen-lockfile flag aided in achieving determinism when a contributing developer made a mistake by not properly checking in a yarn.lock into a SCM system. The --frozen-lockfile flag would cause a build to fail and allow a developer to investigate the CI logs to resolve the issue.

  From the v1 documentation of yarn install:

  If you need reproducible dependencies, which is usually the case with the continuous integration systems, you should pass --frozen-lockfile flag.

  Without --frozen-lockfile, the locked dependencies may not be specified in the yarn.lock in the SCM repository - Yarn will automatically attempt to install a compliant version specified in package.json. This leads to non-deterministic builds, as each time the build is fired on the CI system, the dependency is unlocked and may change (in part due to potential new dependency releases).

The full form of the Yarn v1 command for my use case was RUN yarn install --production=true --frozen-lockfile which optimizes the final runtime build and ensures a deterministic build, or it would otherwise fail when the CI/CD pipeline is fired (which is more desirable than a non-deterministicly-built production image).

As a developer migrating to Yarn v2 for its PnP innovation, the equivalent of these v1 features are necessary to ensure the same CI/CD workflow that was available in Yarn v1. From my understanding, these two functionalities are currently mutually exclusive in Yarn v2 (described in the “Considered Alternatives” section) - only one of these may be picked (and the obvious answer is --production is more important for the end user of the shipped production image). Notably, I would be much less inclined to submit this feature request if the behavior was not already thoroughly supported in v1.

Note: To be more specific, this issue applies to single module projects that are not multi-module workspaces.

---

Possible Solutions

As I see it, there are a couple possible solutions that would resolve this missing functionality:

• (recommended) add a v2 equivalent of v1’s yarn check command allowing Docker developers to do akin to the following: RUN yarn check && yarn workspaces focus --production which would be canonically equivalent to the behavior seen in v1’s RUN yarn install --production=true --frozen-lockfile. A non-zero exit code on inconsistent lockfiles would be beneficial. This solution is, in my opinion, the most viable one - it enables developers to run validity checks on a lockfile without initiating an install.
• add a --production flag to yarn install that works for non-workspaces (i.e. a single module), which currently only supports --immutable (the v2 equivalent of v1’s --frozen-lockfile).
• add an --immutable flag (behaving the same as yarn install --immutable) to the yarn workspaces focus command, which currently only supports --production.

---

Solution Drawbacks

The implementation for all of the above mentioned solutions may be far from trivial with the current architectural design of the current system (or maybe not?). A contributor/maintainer on the project would likely be able to answer that. Yarn v1’s support of this combined functionality is succinct proof this functionality is possible to implement.

---

Considered Alternatives

The current alternative contenders are:

• yarn check; however this command has been deprecated after Yarn v1.
• yarn install --immutable; however, this has no support for --production for installing only production dependencies. Furthermore, this cannot be used to validate the lockfile as it has side effects - the filesystem is modified.
• yarn workspaces focus --production --production, which is also mentioned in the seemingly duplicate issue #1320. However, there is no support for the --immutable/--frozen-lockfile flag. Furthermore, an entire workspaces development plugin should not be the recommended option for simply installing production dependencies for a single-module non-workspace project.
• a third party plugin; however, this has significant security implications (e.g. who is maintaining it - an arbitrary individual or an organization?). Yarn has earned its reputation, other individuals/organizations may not have or may be more susceptible to malicious contributions.
• have other contributing developers on your project always ensure a yarn.lock file is checked into SCM that is consistent with package.json, but hahaha that’s a funny one :^)

This is a core functionality that was available in Yarn v1 - it should also be a core functionality in Yarn v2, and not separated into a plugin.

[kemsky]

This is really confusing, as a new yarn 2 user I have to update my CI worflow, but this path is just too convoluted.

We had yarn install --production=true --frozen-lockfile --non-interactive - perfectly clear and simple. Validates lock file, installs only what is needed for build, supresses all interactions. Is that something uncommon?

Now it takes hours to google replacement for each argument:

• --production=true now requires workspace-tools plugin even if you don’t use any workspaces.
• --non-interactive is not needed anymore, but I had to look through source code to find that.
• --frozen-lockfile is not possible anymore, because as said above, yarn --immutable will run full install (why, why, why… why don’t you put your comment into migration guide?).

[matart15]

@alokdeshwal-st

Thank you. For now, I changed to npm. Will try it next time.