Yarn: Cannot add a regular dependency to a workspace root

Created on 27 Sep 2017 · 35Comments · Source: yarnpkg/yarn

Do you want to request a feature or report a bug?

Bug

What is the current behavior?

Have a monorepo, using workspaces (eg, I use packages for included first party dependencies. Add third party dependencies to node_modules as per normal.

If the current behavior is a bug, please provide the steps to reproduce.

$ yarn add [email protected]
yarn add v1.1.0
error You're trying to add a regular dependency to a workspace root, which is probably a mistake (do you want to run this command inside a workspace?). If this dependency really should be in your workspace root, use the --dev flag to add it to your devDependencies.

I wish to install a third party dependency in node_modules. I am using workspaces but this is a third part module and I would not like it included in my workspace. This is not a mistake. If it somehow is, the error message doesn't explain why.

What is the expected behavior?

A dependency is installed.

node 8.4, yarn 1.1.0

Source

mikemaccana

Most helpful comment

Why are dev dependencies allowed to exist outside workspaces, but non-dev dependencies are?

Both are allowed to exist to make transition easier, but only --dev are allowed to be added via yarn add for the time being. The reason for this is that most people running yarn add <...> inside a workspace root actually want to run it inside a workspace, so we just ask them to use --dev if they really, really want to add it inside the workspace root, since it doesn't make much difference anyway whether they're listed as dev or prod dependency there (workspaces are never published, so they're always in a kind of dev state).

I have plans to change this workflow to use a different --workspace option which should make things much easier to understand, it should be ready for the next release (unless someone want to beat me to the punch and open a PR before that?).

arcanis on 2 Oct 2017

👍2

All 35 comments

From the error message:

use the --dev flag to add it to your devDependencies

Bnaya on 27 Sep 2017

@Bnaya Yes I read that message. It's not a devDependency. It's a production dependency. Making it a devDependency would break deployment as it's required for production.

mikemaccana on 28 Sep 2017

So it should be added as one of your workspaces deps and not on the top level
The top level project shouldn't have any prod code, only dev related stuff

Bnaya on 28 Sep 2017

👍2

@Bnaya Thanks for responding. I;m trying to get a feel for what yarn wants me to do but the messaging here is hard to understand. Is the 'top level code' node modules?

Right now I have:

packages (my original code, included in monorepo)
node_modules (third party packages)

Are you suggesting:

original-packages (my original code, included in monorepo)
thirdparty-packages (third party packages)
node_modules (dev related packages)

mikemaccana on 28 Sep 2017

If it helps: my current set up is based on https://yarnpkg.com/blog/2017/08/02/introducing-workspaces/

mikemaccana on 28 Sep 2017

Ok, i think i got it
What is the sub package you want to add the dep to?
Your add command needs to look like:

yarn workspace jest-matcher-utils add [email protected]

replace jest-matcher-utils with your package name
And you need to run it from the top level dir of the project

Bnaya on 28 Sep 2017

👍2

@Bnaya I'm having the same issue. I tried that command but I'm getting an error that it can't find the workspace. HHMMMMMM

bryzaguy on 28 Sep 2017

It's like this right?
yarn workspace <package_name> add <npm_package_name>

bryzaguy on 28 Sep 2017

@bryzaguy yes,
just a hint, package_name needs to be the name in the package.json and not the directory name under the packages dir

Bnaya on 28 Sep 2017

👍2

I wish to add the package to no workspace, ie, merely to push it to node_modules, as it's not worth including in my monorepo. Exactly like chalk is in the workspace documentation at https://yarnpkg.com/blog/2017/08/02/introducing-workspaces/.

Are you saying this doc is incorrect and all packages should be in a workspace, or not?

mikemaccana on 2 Oct 2017

chalk is saved as dev dependency

"devDependencies": {
    "chalk": "^2.0.1"
  },

Which will work also for you

Bnaya on 2 Oct 2017

@Bnaya How should I handle non-dev dependencies? Are you suggesting:

original-packages (my original code, included in monorepo)
thirdparty-packages (all other third party packages)

Why are dev dependencies allowed to exist outside workspaces, but non-dev dependencies are?

I'm trying to work out what you want me to do but I don't know. If you could answer these questions I (and others in the thread) would be grateful. If you don't know, that's fine too, let me know and I'll stop asking!

mikemaccana on 2 Oct 2017

I don't know what is your usecase, so i don't undestand what's the problem.
each package inside your workspace should have its own dev and none dev deps, inside its own package.json.

yarn install generating single lock file on the root of the project, and hosting the deps when possible (most of the times) to the top level node_modules.

The preventing to add none-dev dependency to a workspace root is a by-design feature of yarn. that's why you have that specific error message.
Why you want a none-dev dependency? what is your usecase? why can't it be just a devDep?

if you really want it there, install as devDep, and manually edit your package.json the yarn.lock will stay the same

If you have a valid use case, without a good workaround i'm sure yarn guys will considering changing it.

Why are dev dependencies allowed to exist outside workspaces, but non-dev dependencies are?
See #4166

Bnaya on 2 Oct 2017

Why are dev dependencies allowed to exist outside workspaces, but non-dev dependencies are?

arcanis on 2 Oct 2017

👍2

I was also confused by this, and in my case it's because I want my workspace root to be my app, and my local packages folder to contain sub-components and/or utilities thereof. For example:

$ tree my-example-project/
├── README.md
├── lerna.json
├── package.json
├── packages
│   └── babel-preset-my-example-babel-setup
│   │   └── package.json
│   └── eslint-config-my-example-eslint-setup
│   │   └── package.json
│   └── my-example-build-scripts
│   │   └── package.json
│   └── my-example-shared-component-library
│       └── package.json
├── public
│   └── index.html
├── src
│   └── index.js
└── yarn.lock

I want my workspace root to list out the top-level third-party dependencies I'm using (e.g. React or Angular or Express or whatever) and be able to make use of my local first-party dependencies (either as dev dependencies or as regular/production dependencies).

An example of my top-level package.json might be (based on create-react-app):

{
  "name": "my-example-project",
  "version": "1.0.0",
  "private": true,
  "scripts": {
    "start": "react-scripts start",
    "build": "react-scripts build",
    "test": "react-scripts test --env=jsdom",
    "eject": "react-scripts eject"
  },
  "dependencies": {
    "react": "^16.0.0",
    "react-dom": "^16.0.0",
    "react-scripts": "1.0.14",
    "my-example-build-scripts": "^1.0.0",
    "my-example-shared-component-library": "^1.0.0",
    // maybe express, whatever else ...
  },
  "devDependencies": {
    "lerna": "^2.3.1",
    "babel-preset-my-example-babel-setup": "^1.0.0",
    "eslint-config-my-example-eslint-setup": "^1.0.0",
    // babel, eslint, etc ...
  },
  "workspaces": ["packages/*"]
}

Does that make sense? Am I think about this entirely incorrectly/expressing an entirely different use case? Thank you in advance for your hard work, care, and attention.

mysterycommand on 4 Oct 2017

👍1

Ah! It's not just me thinking about workspaces in this way, check out this:
http://www.benjiegillam.com/2017/08/switching-graphile-to-yarn-workspaces/
https://github.com/graphile/graphile-build/pull/36/files

mysterycommand on 4 Oct 2017

@mysterycommand you don't have access from the top level package to the workspaces packages.
Only packages under "workspaces": ["packages/*"] see each other.
(I mean unless you publish them the install from your registry, which beats the purpose)

Bnaya on 4 Oct 2017

https://github.com/graphile/graphile-build/pull/36/files

All of their code sits inside packages

Bnaya on 4 Oct 2017

I don't know what is your usecase, so i don't undestand what's the problem.

I wish to add a piece of softare I use for production. It is not my original code, so I'd like to add it to node_modules.

each package inside your workspace should have its own dev and none dev deps, inside its own package.json.

Yes. That's the way I currently get around yarn add being broken:

Add the package to package.json
Run yarn install

The preventing to add none-dev dependency to a workspace root is a by-design feature of yarn.

OK (assuming none-dev means 'non-dev', aka production). Why?

Why you want a none-dev dependency?

Because it's a piece of software I use for production

what is your usecase?

I have a module which my software requires to work.

why can't it be just a devDep?

Because it is not used to develop the software. It is used to run it. If I skipped dev dependencies, which one normally does when deploying to production, the software would break because the dependency would not be installed.

@Bnaya Does this make sense? I think this is a pretty basic thing, I just want to install software and that software isn't used for development and is required for production.

mikemaccana on 5 Oct 2017

👍1

Fwiw this confusion will be cleared by #4630, which should ship with the next release :)

arcanis on 5 Oct 2017

👍1

Thanks @arcanis for your answer which helps a lot (your previous one, looks like we just posted at the same time):

The reason for this is that most people running yarn add <...> inside a workspace root actually want to run it inside a workspace, so we just ask them to use --dev if they really, really want to add it inside the workspace root, since it doesn't make much difference anyway whether they're listed as dev or prod dependency there (workspaces are never published, so they're always in a kind of dev state).

OK. Personally I use devDependencies as they've always been defined, ie development dependencies that are not required for production. So installing to devDependencies doesn't work.

The reason I want to not have the package in my workspace (called packages) is that I own all the code in the workspace: its a mono-repo that includes packages). There's about 80 or so, original modules there.

Third party depdendencies are in node_modules and node_modules is not included in the git repo.

I have plans to change this workflow to use a different --workspace option which should make things much easier to understand, it should be ready for the next release (unless someone want to beat me to the punch and open a PR before that?).

That sounds excellent. Just being able to say --workspace none or --workspace root or whatever would be great,

mikemaccana on 5 Oct 2017

Thanks again @arcanis. Could --ignore-workspace-root-check just be --workspace-root? I'm not doing anything bad by installing something to my workspace root.

mikemaccana on 5 Oct 2017

I'd like to reserve --workspace-root for a possible future usage where it would add the package to the workspace root, wherever you are in the workspace. If the command name is too long, you can use its shorthand, -W.

arcanis on 5 Oct 2017

It's not that it's too long, it's just that it's what I want to do - add it to the workspace root, rather than skipping a check preventing me from doing something bad.

It's like wanting to wear white sneakers, and typing:

clothing --avoid-white-sneaker-check

clothing --wear-white-sneakers

If you get what I mean.

But it sounds like -workspace-root is what I want, and a sensible name for that, so I can happily use the weird check skipping thing until -workspace-root is implemented,

mikemaccana on 5 Oct 2017

PS. Any idea when -workspace-root is coming?

mikemaccana on 5 Oct 2017

Not on my personal roadmap atm, but I'd be happy to review a PR that would implement it 🙂

arcanis on 5 Oct 2017

yarn add X --dev
yarn add v1.2.1
error Running this command will add the dependency to the workspace root rather than 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).
info Visit https://yarnpkg.com/en/docs/cli/add for documentation about this command.

Even with the dev flag I still get this error, do I really need to always add the -W flag to ignore this check even for dev depends?

neurosnap on 27 Oct 2017

Yes. Starting from the 1.2.1, the flag is now --ignore-workspace-root-check, using --dev will not have any particular meaning. If you don't want to type it every time, you can simply define it in your yarnrc and be done with it :)

arcanis on 30 Oct 2017

Thanks @arcanis! 😃 Also I really like --dev not having any special meaning: whether something is production or not is orthogonal to whether it belongs in a workspace or in node_modules. 👍

What exactly is the line we need to add to our .yarnrc?

mikemaccana on 31 Oct 2017

👍1

The following should work:

--ignore-workspace-root-check true

arcanis on 31 Oct 2017

Ah it's consistent, cool.

PS. it's ignore-workspace-root-check true (no dashes) right?

mikemaccana on 31 Oct 2017

The dashes are needed because it's a command line settings, not a classic settings. In short, every setting in your yarnrc that is prefixed by -- will be automatically added to the command line as-is (whereas classic settings require specific code that checks for them).

We now tend to prefer the command line settings (which is why there's no ignore-workspace-root-check settings), because they are quite generic and will support all the flags we might add in the future, without requiring us to add any code.

arcanis on 31 Oct 2017

Ah - thanks @arcanis !

mikemaccana on 1 Nov 2017

@mikemaccana @arcanis can we close this issue then?