Yarn: workspaces request: option to symlink all packages into local node_modules

Created on 21 Aug 2017  路  7Comments  路  Source: yarnpkg/yarn

Feature request: option to symlink modules in node_modules that would normally resolve to their workspace parent directory.

Yarn workspaces works because of the node.js behaviour of looking in parent directories' node_modules when resolving modules.

Webpack doesn't do this by default, to get this behaviour you need to add to the resolve.modules config. Not difficult, but it may trip people up.

But this is harder to work around when you're using something with an automatic webpack config, like create-react-app. To customize webpack in create-react-app, you need to "eject", which causes you to lose a bunch of the advantages of c-r-a.

So thus my feature request: an option that uses symlinks to fully populate node_modules.

Example.

child's package.json has a dependency on foo. All modules in the workspace that depend on foo use the same version, so yarn w/workspaces installs foo into parent/node_modules/foo. My request would be an option that would symlink parent/child/node_modules/foo to parent/node_modules/foo.

cat-feature help wanted needs-discussion triaged

Most helpful comment

After playing around with workspaces for the past few weeks I'm realising that something like this is sorely needed.

I'd really love an option to actually just install every workspace's dependencies locally in each of their folders, and never hoist any modules to the parent directory at all. Along with the symlinks to linked workspace modules.

There are way too many issues that are arising where Node or Webpack or any other kind of module resolving system tends to get confused with the node_modules folder being so fragmented between local and parent. As if the state of JavaScript module resolution wasn't confounded enough... 馃槄

Potentially, linked workspace modules could still be symlinked at the parent. It's mostly about the confusion that arises when one module depends on something different to another module, and different versions are sometimes installed in the parent and local workspace module's node_modules.

All 7 comments

+1 react-native tooling doesn't work unless it sees certain packages in the current directory node_modules. I either have to symlink some of the packages by hand or use npm install for it to work, which kind of defeats the purpose of using yarn workspaces.

Or alternatively having an option to not hoist packages might work better

This is actually also something that would solve problems when having flow in all of the packages, since flow itself does not resolve node_mdoules any higher than the location of the .flowconfig.

Currently I've built a custom script which will create the symlinks for me, but I would love to see if yarn would've such a feature implemented by default. :)

After playing around with workspaces for the past few weeks I'm realising that something like this is sorely needed.

I'd really love an option to actually just install every workspace's dependencies locally in each of their folders, and never hoist any modules to the parent directory at all. Along with the symlinks to linked workspace modules.

There are way too many issues that are arising where Node or Webpack or any other kind of module resolving system tends to get confused with the node_modules folder being so fragmented between local and parent. As if the state of JavaScript module resolution wasn't confounded enough... 馃槄

Potentially, linked workspace modules could still be symlinked at the parent. It's mostly about the confusion that arises when one module depends on something different to another module, and different versions are sometimes installed in the parent and local workspace module's node_modules.

It would be helpful to define somewhere what yarn workspaces should do vs what a third party tool like lerna should do. The docs say

Yarn鈥檚 workspaces are the low-level primitives that tools like Lerna can (and do!) use. They will never try to support the high-level feature that Lerna offers, but by implementing the core logic of the resolution and linking steps inside Yarn itself we hope to enable new usages and improve performance.

Which gives me the general idea that yarn workspaces should only do what a third party tool can't do efficiently itself (like installing dependencies for all packages). It seems like there's not much of an issue creating symlinks locally for a tool like lerna.

Webpack doesn't do this by default, to get this behaviour you need to add to the resolve.modules config. Not difficult, but it may trip people up.

This definitely tripped me up and your note about it helped resolve my issue. Thanks!

This is how I solved this issue:

Instead of defining foo on the package.json of each workspace, what I did was to have it defined only on the root package.json with the version that you want to use.
Then on each workspace package.json you just have to add foo: link:../node_modules/foo

When you do yarn install, it will install foo on the root node_modules folder and have a symlink to it on each workspace node_modules.

Take in account that if you have defined a resolution version of foo in the root package.json, the symlink wont be created.

It would be great if we could turn off the symlinking of packages in the packages/ directory. I have a project that depends on the published version of a package in packages/ to build all packages. Yarn symlinks all packages/ for the top-level node_modules which results in the remote (and published) version of the package not being downloaded and installed.

Was this page helpful?
0 / 5 - 0 ratings