Berry: [Bug] Berry is not allowing installs in my monorepo

[Tirke]

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... ")

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.

[arcanis]

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.

It may be easier for you, but not for us. Using a standardized workflow isn't only meant to help you, but also to help us help you 🙂 Anyway,

YN0014: │ @da/iot-parser@npm:^3.8.0: Only some patterns can be imported from legacy lockfiles (not "https://artifactory.tools... ")

Yep, cf https://yarnpkg.com/advanced/error-codes#yn0014---yarn_import_failed

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

Yes, this is expected. From Yarn's point of view, the folders where you're running your commands should be part of the project somehow (otherwise where would it store the dependencies, when you run yarn add?), but they aren't declared as such and it doesn't know what to do of it.

[Tirke]

Thanks for your detailed answer @arcanis. I think I mislabeled this issue as a bug, it's more an exploration of berry's limitations. My current workflow is perfectly supported by yarn v1 so it's kind of a regression for us and I need to prepare for the future. (also would benefit a lot from an atomic cache)

Do you think it's possible for me to have this organization without workspaces, using berry?

| root - package.json with devDependencies only + root node_modules
| packages  | package-1 | node_modules + package.json
            | package-2 | node_modules + package.json
            | package-3 | node_modules + package.json

Maybe I'm lacking some knowledge but I don't think that Yarn can do this natively.
I'm willing to declare package-1 , package-2 as being part of a global project (that would be root here). But I also really need to have a way of getting the actual node_modules containing only the dependencies of package-1 before packing it. Whereas with workspaces I would only get one node_modules in the root directory.

Is there a way to force an install of node_modules inside only one package using yarn workspaces?

Thanks for your help.

[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.

[elmpp]

@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.

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? Would this be triggered from the project base during a normal install?

[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.

[larixer]

I close this issue, since I think all points have been discussed and addressed. Feel free to reopen/open another one if you think some concern has not been addressed, but it should.