yarn workspaces is not compatible with bazel-managed deps

[alexeagle]

yarn workspaces lays out node_modules in several directories, nested with your source code. It relies on node module resolution semantics of looking for a node_modules in parent directories when a dependency isnt' resolved

Bazel-managed dependencies are in a single node_modules directory that's outside the source code.

We could have multiple bazel-managed node_modules, but would still need each of these to be a complete copy of deps needed for a given binary to run.

[clydin]

Another viable dependency management method for monorepos is to run npm/yarn/pnpm individually for each package and the root of the monorepo. This would also cause issues with Bazel.

[alexeagle]

Plan: advertise that yarn workspaces doesn't work.
The same use case can be achieved by having multiple independent package.json files.
Maybe we need some tooling to convert from one to the other.

[alexeagle]

Actually, having Bazel lay out its managed dependencies into multiple node_modules directories that live in your sources could work.

[alexeagle]

@kyliau could you update the developer doc to explain a bit how contributors and people on the team should treat the package.json file now that we are in a mixed mode?

@clydin I think we could discuss not using yarn workspaces. Given our current setup, a third-party dep has to go in two places, so we already broke the one thing we know of that yarn workspaces was helping with.

@irengrig this is where we really need Bazel to lay out dependencies inside the project folder, FYI

[clydin]

workspace support is being tracked/discussed here: bazel-contrib/rules_nodejs#266

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}