Do you want to request a feature or report a bug?
What is the current behavior?
Using yarn workspaces for a monorepo which includes a top level node module creates only a single
yarn.lock at the root of the monorepo, with no
yarn.lock that is specific for the top level node module.
What is the expected behavior?
I want to use yarn workspaces to manage a monorepo that includes both apps (top level node modules) and libraries. But having only a single
yarn.lock file at the root of the monorepo prevents me from packaging my app into a docker image for example. I would love a way to get a
yarn.lock file for chosen workspaces that need to have one of their own, because that workspace may later be used outside of the monorepo.
If I have a monorepo with 2 workspaces:
workspace-a uses some of the exported modules from
workspace-b. If I want to package
workspace-a into a docker image (or any other way of packaging that workspace by itself, without the whole monorepo), I don’t have a
yarn.lock for it. That means that when I’ll move the files of
workspace-a into a different environment apart from the monorepo, I’ll be missing a
yarn.lock file and when installing dependencies, I’ll lose all the advantages of a lock file (knowing I’m installing the same dependencies used in development).
I’m quite surprised I couldn’t find an issue about this. Am I the only one who wants to work with monorepos that way? Maybe I’m missing something? My current workaround is using
lerna without hoisting at all, so I’ll have a lock file per package.
The recently released
nohoist feature also doesn’t seem to help (though I hoped), as it doesn’t create a different
yarn.lock per workspace.
This issue is somewhat related to this comment on another issue. Thought that it may deserve an issue of its own.
Please mention your node.js, yarn and operating system version.
node 8.9.3, yarn 1.5.1, OSX 10.13.3