Workspaces and lockfiles

[arcanis]

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.

[rtsao]

Are there any known workarounds for this?

[arcanis]

Not yet, open to any idea

[rtsao]

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.

[chambo-e]

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

[jeremiegirault]

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.

[tdfairbrother]

@jeremiegirault I looked at this but generate-lock-entry doesn't seem to work properly https://github.com/yarnpkg/yarn/issues/2340

[RDeluxe]

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.