yarn link does not install package dependencies

[OliverUv]

Bug.

What is the current behavior?

oliveruv@computer~/w/yarnbug> tree .
.
├── library
│   └── package.json
└── user
    └── package.json

2 directories, 2 files

oliveruv@computer~/w/yarnbug> cat user/package.json
{
  "name": "user",
  "version": "1.0.0",
  "description": "Target project for yarn link",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "",
  "license": "ISC",
  "repository": {
    "type": "git",
    "url": "git://github.com/OrKoN/npm-link-shared.git"
  },
  "private": "true",
  "dependencies": {
    "module-a": "*"
  }
}

oliveruv@computer~/w/yarnbug> cat library/package.json
{
  "name": "library",
  "version": "1.0.0",
  "description": "library that depends on other packages",
  "main": "index.js",
  "repository": {
    "type": "git",
    "url": "git://github.com/OrKoN/npm-link-shared.git"
  },
  "private": "true",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "",
  "license": "ISC",
  "dependencies": {
    "lodash": "*"
  },
  "devDependencies": {
    "chai": "*"
  }
}

oliveruv@computer~/w/yarnbug> cd library/

oliveruv@computer~/w/y/library> yarn link
yarn link v0.21.3
success Registered "library".
info You can now run `yarn link "library"` in the projects where you want to use this module and it will be used instead.
Done in 0.12s.

oliveruv@computer~/w/y/library> cd ../user/

oliveruv@computer~/w/y/user> yarn link library
yarn link v0.21.3
success Registered "library".
Done in 0.12s.

oliveruv@computer~/w/y/user> cd ..

oliveruv@computer~/w/yarnbug> tree .
.
├── library
│   └── package.json
└── user
    ├── node_modules
    │   └── library -> ../../library
    └── package.json

4 directories, 2 files

oliveruv@computer~/w/yarnbug> yarn --version
0.21.3

oliveruv@computer~/w/yarnbug> node --version
v6.10.0

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

What is the expected behavior?

The last tree . command should show that library has a node_modules directory with lodash installed into it. npm seems to run install on every linked package.

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

oliveruv@computer~> cat /etc/os-release
NAME="Ubuntu"
VERSION="16.10 (Yakkety Yak)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 16.10"
VERSION_ID="16.10"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="http://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=yakkety
UBUNTU_CODENAME=yakkety

oliveruv@computer~> npm --version
3.10.10

oliveruv@computer~> yarn --version
0.21.3

oliveruv@computer~> uname -srvp
Linux 4.8.0-41-generic #44-Ubuntu SMP Fri Mar 3 15:27:17 UTC 2017 x86_64

[OliverUv]

Waiting on this here OrKoN/npm-link-shared#10

[OliverUv]

Ah, sorry, expected behavior is that lodash, chia, and their dependencies will be installed in library/node_modules, not just lodash.

With yarn link --production or yarn link --production=true only lodash should exist.

Note: npm does the installation during the first invocation of npm link while standing in ./library/

[OliverUv]

Another addition to this:

I have actually found the current behavior to be better than npm's behavior! My use case: Using docker volumes to mount dependencies so that I can npm link them during development. The npm link call inside the docker container will error out, because npm does not have write access to the outside folder (and I would prefer not to a+rwx/0775 it). This allows the developer to execute npm install etc in the environment where they are developing the external module, instead of having npm do this automagically whenever it feels like it.

If you do add implement this to reach feature parity with npm, I would love a method to opt out of this time consuming and, for me, environment breaking behavior, e.g. with a flag like yarn link --no-install.

[wclr]

using yarn link with installing dependency and without changing package.json/yarn.lock would causes inconsistency in dependency set. Actually using yarn/npm link causes kind of inconsistency anyway and brings a lot of other issues. Yarn installes only dependencies that derive from package.json and this is consistent approach. So far I use yalc for working with local packages.

[binoculars]

The only way yarn link is actually useful is if it installs dependencies. Most packages have dependencies and if you're testing one package in another, you need those dependencies.

[wclr]

@binoculars yalc

[binoculars]

@whitecolor I don't want to

[mmmurf]

I would want yarn link to also install deps that are linked by the package I'm linking... IOW I might have multiple nested "links" that I want to all link to the working directory for that project. Is this possible? It doesn't seem to be the default behavior.

[mosermanuel]

Hi, any updates on this?
Today it is rather difficult to test a new library (with usage of yarn link because it's not published yet). I can only test it by adding all subdependencies via "yarn add" in the application using my library (application -> library -> subdependencies). After the first publish I have to remove all those subdependencies from the application again.

[james-rabbit]

My workaround so far has been to use a build script that does yarn install on everything that is depended on with link before doing yarn install on the main package which requires them.
It's not ideal, but I think it is a bit simpler than other workarounds.

I would absolutely want link (or even something new like link-install) to automatically do this. Maintaining the build script logic separately undermines some of the benefits of using package management, I feel a bit gross using it 😄.