Berry missing mutex argument

[josephjthomas]

Hey,

I'm in the process of upgrading from yarn v1 to berry. On v1, I use yarn --mutex network but berry doesn't offer support for it.
Is there an alternative option to use for berry to warrant this functionality from v1?

[jongwooo]

@josephjthomas --mutex option does not exist in berry. And as far as I know, there is no alternative.

[josephjthomas]

That's why I'm asking.
In Yarn 1 it exists https://classic.yarnpkg.com/en/docs/cli/#toc-concurrency-and-mutex
It's an important flag to warrant concurrency is treated properly. If nothing like that exists in berry (yet), I have to stay on Yarn 1.
I can't risk to lose such an important feature.

[arcanis]

What's the exact scenario you're protecting against? Running yarn install in multiple different projects is already safe. Within the same project we don't have specific guards, with the expectation that it's not clear why you'd run multiple yarn install in the same folder concurrently.

[marlon-tucker]

We have the following use case where we use --mutex network

• We have a yarn workspace structure, where the root lists various shared packages all our workspace projects rely on.
• Each workspace may or may not have it's own set of dependencies it needs.

Now, in our case, the workspace projects are actually part of c# projects, and as such, have their own build pipeline (dotnet / msbuild etc). For each of those projects, yarn install is called which can happen in parallel.

However, as far as yarn is concerned, these share the same "project" node_modules.

My gut says Berry no longer supports this edge case?

Are you able to suggest any viable workarounds?

[arcanis]

Why don't you call yarn install a single time before calling your various builds?

[marlon-tucker]

That isn't easily achieved via dotnet or msbuild, each project is considered distinct. I could maybe create a shim project which the others depend on, but that would introduce a dummy dll into the build output.

This is to prevent team members from having to manually do an install command when they pull changes.