yarn add with workspaces doesn't install to workspace root

[edorivai]

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

What is the current behavior?
Running yarn add foo inside a workspace directory does two unexpected things;

1. it installs the newly added dependency in /my-workspace/node_modules/foo, whereas I would expect it to install it to the workspace root, e.g.: /node_modules/foo
2. it installs all other dependencies of my-workspace to /my-workspace/node_modules

If the current behavior is a bug, please provide the steps to reproduce.
See also: https://github.com/edorivai/workspace-test

1. Create an empty directory(workspace-1), and add a minimal package.json file.
2. In root package.json, set "workspaces": [ "./*" ]
3. Run:

cd workspace-1
yarn add lodash.assign

4. By now, I'd have (also see screenshot)

/workspace-1
  /node_modules
    /lodash.assign

What is the expected behavior?
I would have expected

/node_modules
  /lodash.assign
/workspace-1

With node modules being installed at the root level.

Please mention your node.js, yarn and operating system version.

$ uname -srvo
Linux 4.4.0-93-generic #116-Ubuntu SMP Fri Aug 11 21:17:51 UTC 2017 GNU/Linux

$ lsb_release -rcd
Description:    Ubuntu 16.04.3 LTS
Release:        16.04
Codename:       xenial

$ node --version
v8.5.0

$ npm --version
5.3.0

$ yarn --version
1.0.2-20170921.1145

[BYK]

I was able to replicate this behavior locally with the repo provided. @bestander I'm guessing this was not intentional?

[bestander]

Yeah, for sure does not look like it is intentional.
Result of yarn add should leave node_modules in the same state as yarn install run after it, hoisting rules should apply.

[edmorley]

Fwiw this reproduces with yarn 1.2.0 (ie after #4630 and #4654).

[BYK]

@edmorley how about after #4730?

[edmorley]

This now works for me using latest yarn Nightly.

ie:

src $ mkdir yarn-test
src $ cd yarn-test/
yarn-test $ echo '{"workspaces": [ "./*" ]}' > package.json
yarn-test $ mkdir workspace-1
yarn-test $ cd workspace-1/
workspace-1 $ yarn init -y
...
workspace-1 $ yarn add lodash.assign
yarn add v1.2.1-20171031.1106
warning ..\package.json: No license field
info No lockfile found.
[1/4] Resolving packages...
[2/4] Fetching packages...
[3/4] Linking dependencies...
[4/4] Building fresh packages...
success Saved lockfile.
success Saved 1 new dependency.
└─ [email protected]
Done in 0.48s.
workspace-1 $ ls -1 node_modules/
lodash.assign
workspace-1 $ ls -1 ../node_modules/
ls: cannot access '../node_modules/': No such file or directory

Note: yarn init -y is required in workspace-1 before the yarn add otherwise the "Running this command will add the dependency to the workspace root rather than workspace itself, which might not be what you want" warning is shown. Perhaps that warning (and me adding the yarn init) is actually the real fix that helped here?

[BYK]

@edmorley yay, thanks! Closing then :)

[edorivai]

@edmorley I'm most probably missing something, but as I read it, the behavior that you're showcasing is exactly the bug that I'm describing.

[edmorley]

Ah sorry - seems like I inverted the expected-actual from the OP when comparing to my results.

However repeating your STR (that don't have the yarn init -y) now results in:

src $ mkdir yarn-test
src $ cd yarn-test/
yarn-test $ echo '{"workspaces": [ "./*" ]}' > package.json
yarn-test $ mkdir workspace-1
yarn-test $ cd workspace-1/
workspace-1 $ yarn add lodash.assign
yarn add v1.3.2
warning package.json: No license field
info No lockfile found.
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.

Repeating my steps from above (that used yarn init -y before the install) gives the same log output as before.

So it seems there are a few issues:

1. Yarn behaves differently depending on the presence of package.json in the workspace directory, which seems like a bug?
2. For your workflow, what's the recommended way of achieving that result (eg running a different command from the root instead), or should it "just work" when yarn adding from a workspace?

[edorivai]

I think it would be the most intuitive if a yarn add within workspace-1 would install to /root/node_modules instead of to /root/workspace-1/node_modules. Even more so because when I check my changes in to source control, and my colleagues run yarn in /root, I expect the new dependency for workspace-1 to be added to the root.

Does this expectation make any sense? What is the recommended workflow for adding a dependency to a workspace? FYI, my current workflow is manually editing package.json files, and running yarn from root afterwards. This feels a bit cumbersome.

[edorivai]

@BYK @edmorley I think this issue should be reopened. I just went over the test repo again, currently with [email protected], and the behavior as outlined in the repo persists.

[rally25rs]

Reopening because the issue seems to depend on the workspace location.

If you use

"workspaces": ["packages/*"]

then adding a package in a workspace project properly installs it to the workspace root /node_modules

However if you use

"workspaces": ["./*"]

then adding a package in a workspace project installs it to that project /some-pkg/node_modules

(reproduced in yarn v1.7.0)

[samuela]

I just came across this exact issue with

"workspaces": ["packages/*"]

and yarn v1.13.0. I tried both yarn add ... in packages/my-package and yarn workspace my-package add ... in the root directory.

This really defies everything that it seems like workspaces are supposed to fix, so it's making me reconsider my setup now.

[Axedyson]

This is still happening for me using yarn v3.0.2