-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Workspaces and lockfiles #4206
Comments
Are there any known workarounds for this? |
Not yet, open to any idea |
In any case, it seems like the workspace A possible solution: what if the relevant subset of the 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 |
What about a A This is just a thought, no idea if it can be done |
Hi, |
@jeremiegirault I looked at this but |
That's also problematic for CI/CD, docker, etc. |
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.
The text was updated successfully, but these errors were encountered: