[Bug] Berry is not allowing installs in my monorepo

Environment:

• OS: OSX latest
• Node version v12.16.1
• Yarn version 2.0.0-rc.29

Describe the bug

I have a monorepo for lambda functions setup in an exotic way. I have a root package.json with some devDependencies. The root package is private and useless and it contains one directory (lambdas) filled with all my actual packages (one per lambda). So this is very much a monorepo. The twist is that I don’t use Lerna nor Yarn workspaces. It is more easier that way because I need to have the actual node_modules with all dependencies of each package before zipping it for AWS deployment.

I migrated the root directory of this monorepo using yarn set version berry. I saw that it created a .yarn directory with a binary inside + a .yarnrc.yml. I thought that I can reuse the binary in the .yarn dir by just putting a .yarnrc.yml pointing to it in each of my packages. It worked at first but my old yarn.lock doesn’t seem to be compatible with Berry. YN0014: │ @da/iot-parser@npm:^3.8.0: Only some patterns can be imported from legacy lockfiles (not “https://artifactory.tools… <private artifactory url>”)

Next, I delete the yarn.lock and now I can’t even install :

The nearest package directory (lambda/package/path) doesn’t seem to be part of the project declared at /root/package/path. If the project directory is right, it might be that you forgot to list a workspace. If it isn’t, it’s likely because you have a yarn.lock file at the detected location, confusing the project detection.

Is there a way to make my monorepo work with berry? I need to keep the constraint of having node_modules present in each package or having a way to install all dependencies of each package before zipping.

[larixer]

@Tirke Please note, that you can actually have this workflow working with berry now - when you have several packages managed/installed independently, you need to:

cd packages/package-1
touch yarn.lock
yarn

cd packages/package-2
touch yarn.lock
yarn

You don’t necessarily need to copy .yarnrc.yml into all these projects, if they are all the same, if it enough to have one .yarnrc.yml in the root folder. But if they are different, you might want to have separate .yarnrc.yml in each package-foo.

[larixer]

Am i right in believing that the presence of a yarn.lock file in a workspace will force all workspace dependencies to be contained in n_m?

Yes

Would this be triggered from the project base during a normal install?

No, these will be effectively separate projects from the yarn point of view.