Two important limitations with workspaces and lockfiles that have been brought by @jeanlauliac:
Let's say we have ten different packages. We want all of them to live in their own repository so that people can work on them independently if they want, but we also want to be able to link them together if we need to. To do this, we have a mega repository with a submodule for each package, and a package.json that references each of these submodule as a workspace.
First problem: If we run yarn add
inside a package from within this workspace, the lockfile will be created inside the workspace root. There won't be any lockfile inside the individual packages. Because of this, someone working on the individual package repository will not use the same dependencies as someone using the workspace.
Second problem: This is actually the reverse problem. Someone adding a dependency from the individual package repository will add the dependency version to the individual lockfile. Because of this, users of the workspace might not use the same version (because their source of truth will be the workspace root's lockfile).
Not sure these problems are solvable. Just something to keep in mind, and maybe we can come up with some kind of smart solution.
Are there any known workarounds for this?
Not yet, open to any idea
In any case, it seems like the workspace yarn.lock
file should be the source of truth.
A possible solution: what if the relevant subset of the workspace yarn.lock
was continuously written to the each individual package. These individual package lockfiles would be ignored by yarn if the package is in a workspace, but would work normally if cloned outside of a workspace.
The last piece would be detecting and resolving conflicts between the workspace and individual lockfiles. These conflicts would arise if an individual repo was updated outside of the workspace.
Alternatively, maybe workspaces could be re-implemented using individual lockfiles instead of a top-level yarn.lock
.
What about a mode
? Kinda like lerna does.
A global
mode with the actual behavior, there is one yarn.lock
at the workspace top level.
And an independent
mode where each package has its own yarn.lock
and none at the top level. When the install is made on the full monorepo yarn will internally merge every yarn.lock
and install deps without writing a lockfile. When the install is made locally, yarn act just like usual without considering the workspace
This is just a thought, no idea if it can be done
Hi,
In the root package of my lerna repo I'm using a postinstall
script like this one lerna exec -- "yarn generate-lock-entry > yarn.lock"
It seem to work and generate appropriate lockfiles.
@jeremiegirault I looked at this but generate-lock-entry
doesn't seem to work properly https://github.com/yarnpkg/yarn/issues/2340
That's also problematic for CI/CD, docker, etc.
I have a docker-compose file at my root, and Dockerfiles in each of my package. Sadly if I want to do things correctly and use the package folder as its build context, I can't access the yarn.lock file and will bump into the first problem quoted before.
Most helpful comment
That's also problematic for CI/CD, docker, etc.
I have a docker-compose file at my root, and Dockerfiles in each of my package. Sadly if I want to do things correctly and use the package folder as its build context, I can't access the yarn.lock file and will bump into the first problem quoted before.