[x] This feature is important to have in this repository; a contrib plugin wouldn't do
Describe the user story
Not all security/dependency scanners are created equal. Whereas npm audit might be able to differentiate between dependencies and devDependencies (via yarn npm audit --environment production for instance), other tools might not.
Our enterprise has multiple such tools which can parse the yarn.lock, but cannot augment the lock-file with all the relevant workspace package.json files to reliably determine exactly which artifacts are "production" and which are not.
In Yarn 1 we used to have a workaround for this:
yarn install --production
Which would generate a newyarn.lock file which only contained the production dependencies. This reduced the amount of "noise" in the security scans drastically for our massive mono-repository.
In Yarn 4 however, there is no such option. The documentation and discussions mention this replacement:
yarn workspaces focus --all --production
But that doesn't actually modify the yarn.lock. It doesn't even generate a new one of the file is completely absent.
Describe the solution you'd like
The same yarn install --production[=true|false] that we used to have with Yarn 1, which did the trick neatly.
Plus a way like yarn install --ignore-scripts so that workspace postinstall scripts don't trigger (which often require devDependencies). And yes: I have read https://github.com/yarnpkg/berry/issues/4780#issuecomment-1219778585 but that assumption ignores use-cases like this.
Describe the drawbacks of your solution
I am not familiar enough with the intricacies of Yarn 4 to really comment. As a laymen: "none" of course ;).
Describe alternatives you've considered
Writing a bash+jq script that parses all package.json files in the repository and removes alldevDependencies and then generates a new yarn.lock file.
No idea if that would actually work.
Describe the user story
Not all security/dependency scanners are created equal. Whereas
npm auditmight be able to differentiate betweendependenciesanddevDependencies(viayarn npm audit --environment productionfor instance), other tools might not. Our enterprise has multiple such tools which can parse theyarn.lock, but cannot augment the lock-file with all the relevant workspacepackage.jsonfiles to reliably determine exactly which artifacts are "production" and which are not.In Yarn 1 we used to have a workaround for this:
Which would generate a new
yarn.lockfile which only contained the production dependencies. This reduced the amount of "noise" in the security scans drastically for our massive mono-repository.In Yarn 4 however, there is no such option. The documentation and discussions mention this replacement:
But that doesn't actually modify the
yarn.lock. It doesn't even generate a new one of the file is completely absent.Describe the solution you'd like
The same
yarn install --production[=true|false]that we used to have with Yarn 1, which did the trick neatly.Plus a way like
yarn install --ignore-scriptsso that workspacepostinstallscripts don't trigger (which often requiredevDependencies). And yes: I have read https://github.com/yarnpkg/berry/issues/4780#issuecomment-1219778585 but that assumption ignores use-cases like this.Describe the drawbacks of your solution
I am not familiar enough with the intricacies of Yarn 4 to really comment. As a laymen: "none" of course ;).
Describe alternatives you've considered
Writing a
bash+jqscript that parses all package.json files in the repository and removes alldevDependenciesand then generates a newyarn.lockfile. No idea if that would actually work.