Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

workspaces request: option to symlink all packages into local node_modules #4219

Open
bryanlarsen opened this issue Aug 21, 2017 · 8 comments

Comments

@bryanlarsen
Copy link

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.

@lapluviosilla
Copy link

lapluviosilla commented Aug 23, 2017

+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

@Inkdpixels
Copy link

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. :)

@lostpebble
Copy link

lostpebble commented Nov 9, 2017

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.

@bdwain
Copy link
Contributor

bdwain commented Feb 11, 2018

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’s 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.

@amkoehler
Copy link

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!

@luisgrases
Copy link

luisgrases commented Jun 4, 2020

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.

@paulbrittain
Copy link

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.

@steve-taylor
Copy link

Bolt does this right out of the box.

The main caveats:

  • In addition to declaring your dependencies in each package's package.json, you also have to declare them in the root package.json.
  • Dependency versions have to match across all packages, otherwise the bolt command will fail.

If you can live with these differences, each package's node_modules folder contains symlinks to the required packages in the root node_modules folder.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

10 participants