why does yarn warn when adding a dependency to the root workspaces package.json
Asked Answered
P

3

49

Whenever I add a dependency to the root of the workspaces project:

e.g.

yarn add assets-webpack-plugin -D

I get the following error:

Running this command will add the dependency to the workspace root rather than the workspace itself, which might not be what you want - if you really meant it, make it explicit by running this command again with the -W flag (or --ignore-workspace-root-check).

The alternative is to add it to every project that needs it and then it will you have the problem of each project having different dependencies and lock files.

Petry answered 8/7, 2018 at 19:16 Comment(0)
B
54

Since you are using Yarn Workspaces and it manages the dependencies of all projects (workspaces), you should add dependencies of each project to its own package.json, not the workspace root. Yarn uses only one yarn.lock file that is placed in the workspace root. Also, it tries to move dependencies of all projects to node_modules of workspace root to prevent duplication as much as possible. Although some dependencies need to be placed in node_modules of their own project; e.g. when the workspace root has a devDependency to [email protected] while a project has a dependency to the same package with another version, say 1.2.5 which they are not compatible. Suppose the directory structure of your workspaces is like the following:

├── workspace-root
|   ├── package.json
|   ├── workspace-a
|   |   ├── package.json
|   ├── workspace-b
|   |   ├── package.json

After running yarn either in the workspace root or in any workspace directory, you will have the following directory structure:

├── workspace-root
|   ├── node_modules
|   ├── package.json
|   ├── yarn.lock
|   ├── workspace-a
|   |   ├── package.json
|   |   ├── node_modules
|   ├── workspace-b
|   |   ├── package.json
|   |   ├── node_modules

Only add a dependency to workspace root when you want to run a script from workspace root and it needs a dependency. In this case, the projects are independent of that dependency, so you can ignore that warning.

Why does yarn warn?

If you add the common dependencies of the projects to the workspace root, it won't come in package.json of the projects. Therefore, if you separate a project, it won't have all of its dependencies in its own package.json so running yarn install for the separated project leads to not having all the dependencies in its own node_modules. Obviously the separated project cannot work and you need to fix the absent dependencies problem to resolve the issue.

More about Yarn Workspaces

Yarn Workspaces is a feature for the sake of easier managing dependencies of projects that are related to each other. For example, when your projects have similar dependencies, you can declare each project as a workspace. It prevents a lot of duplication. Another important use case is monorepos:

Those who have tried splitting a project into multiple packages know how hard it is to make changes across multiple packages at one time. To make the process easier, some big projects adopted a monorepo approach, or multi-package repositories, which reduces the burden of writing code across packages.

Several projects used every day by JavaScript developers are managed as monorepos: Babel, React, Jest, Vue, Angular.

Using Yarn Workspaces brings the following benefits:

  • It allows you to setup multiple packages in such a way that you only need to run yarn install once to install all of them in a single pass.
  • Your dependencies can be linked together, which means that your workspaces can depend on one another while always using the most up-to-date code available.

  • This is also a better mechanism than yarn link since it only affects your workspace tree rather than your whole system.

  • All your project dependencies will be installed together, giving Yarn more latitude to better optimize them.

  • Yarn will use a single lockfile rather than a different one for each project, which means fewer conflicts and easier reviews.

Bloodworth answered 30/11, 2018 at 13:46 Comment(7)
Your answer addresses the intended use of workspaces, but not an actual explanation of the error cause. I have the same issue and I've never done anything with yarn workspaces with this project (or elsewhere I can think of). To use Yarn without this message, must I now adopt workspaces? Must I add/change something in package.json?Proctoscope
@Proctoscope I have exactly explained the cause of the error message. In the question, it has been explained how to avoid the error message: by running this command again with the -W flag (or --ignore-workspace-root-check).Bloodworth
I'm confident assumptions are being made in this, but I think I lack the knowledge to spot them. I would start my own question, but I expect it would be marked duplicate to this one because it is the exact same question. An important fact though is that I don't use workspaces (knowingly anyhow) nor am I building "monorepos". As a result, I'm not even sure what a "root workspace package.json" is precisely. I know what MY project package.json is (like every other I've ever worked with), but suddenly yarn is giving me this warning and making me use -W. Question stands, "why"?Proctoscope
The workspace root is simply the parent directory of the project directory. I hope the sample directory hierarchy would be illustrative.Bloodworth
It is and now I am properly back to the same question as the OP because that has no bearing on my project (no mono-repos, no workspaces setup/used, just an error about a feature I'm not presently concerned with. I look forward to seeing if these help the OP or if they are in the same boat as I. This is only happening on one of my projects. My structure is projects/client/project. Nothing more complex than that overall.Proctoscope
When all all else fails, go back to the basics. In my case, I did find "workspaces" declared in my package.json and when removed, the warning is gone. Mystery solved. Question now is why was I getting the error to begin with (which is how I ended up with it there I think). :/Proctoscope
@rainabba, as soon as your root package.json has the "workspaces" option, you effectively "turn on" workspaces for your project, and so that warning was enabled.Gilberto
P
6

If you have "workspaces" declared in your package.json; you've opted into workspaces and setup must be correct. This appears to only make sense if you're using a mono-repo. As it pertains to this, a mono-repo is one large repo with a "root" package.json where workspaces are declared as well as dev-dependencies. Inside it will be other "packages" (projects with their own package.json, but not their own repo).

When you want to add packages to those "workspaces" ( see https://yarnpkg.com/lang/en/docs/workspaces/ ) or "packages" and you're working from the root folder, you must specify the workspace you're targeting the Yarn action with.

If it's a dev-dependency for the root, this is a non-issue. Since it's assumed that your "root" project won't have it's own "production" dependencies and they should only be in the workspaces. If it's not a dev-dependency and you don't specify the workspace ( https://yarnpkg.com/en/docs/cli/workspace ), then you will see the warning and how to override.

Proctoscope answered 24/8, 2019 at 20:21 Comment(2)
I'm really lost. How can you install a dependency for one of your workspaces? cding into my workspace and running yarn add somepackage creates a new lockfile. Running yarn workspace workspace-package-name add somepackage also creates a new lockfile in that workspace.Estray
@Estray like this 'yarn workspace my-sub-package add rxjsOverman
S
1

Simple Answer

You may not have indexed into the correct directory of your app.

For example, you may have a next.js app structured like this:

myApp
- /app
- /functions

Yarn will throw this warning if you're trying to remove a package while in the myApp directory in your IDE terminal. So, the solution may be as simple as this:

cd /app
yarn remove somePackage
Sacrarium answered 19/12, 2022 at 23:0 Comment(0)

© 2022 - 2025 — McMap. All rights reserved.