When using Yarn workspaces, can I install every devDependency in the root workspace? Or should I keep them in each separate workspace?

user_10128619 0
Viewed 2504

When using Yarn workspaces, can I install every devDependency in the root workspace? Or should I keep them in each separate workspace?

For example:

packages
  package1
    package.json
  package2
    package.json
  package3
    package.json
package.json

And here are the needed devDependencies for each package.

package1 => external-package-A
package2 => external-package-A
package3 => external-package-A + external-package-B

Where should a install the external-package-A and external-package-B ?

Should a install external-package-A in the root workspace, since it's used by all of my packages?

Will there be any problem if I also install external-package-B in my root workspace?

Or should I install them in each of the packages? What I mean is they'd be listed in each respective package.json file for each package, instead of being listed in the root one.

yarn-workspaces package.json yarnpkg dependency-management
1 Answers

Here is what I've found on Reddit.

https://www.reddit.com/r/javascript/comments/9t6yht/yarn_workspaces_why_is_adding_something_to_the/

Comment 1

It's not bad. It's just have to be explicit.

For example, you have package A. It relies on external dependency B. If you install B into root, you'll get package A working inside workspaces, but on install it will fail. All your dev dependencies, which is not called from workspace alone can be installed to root with no problems.

For example, we have babel in every workspace (different versions in different packages), but have eslint in root. We're working towards unified build process, so babel will also migrate to root deps.

Comment 2

Disclaimer: I'm working on implementing a company-wide monorepo at Uber.

Two reasons.

It's "bad" if you are publishing each package separately. If you do that, then when you install it elsewhere, a required dependency will be missing from its package.json.

If you are in a large company-wide monorepo (or any monorepo large enough that it has several separate teams working on separate packages), then upgrading a top-level dep that everyone depends on can be very difficult to land, since it may require code reviews from dozens of people, and the diff may break people's packages in ways that tests may not catch (and that's without counting things like packages that no longer have active maintainers).

Having deps in the top level is a strategy known as locked dependencies and it does have some theoretical benefits (e.g. only a single version of every direct dep, and thus faster installs, CI, etc), but in practice, it's very expensive to maintain, compared to the unlocked dependencies strategy (no deps at top level).

user_101286190
Related