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

Does not link nested dependencies when they are inside the root node_modules folder #37

Open
spoldman opened this issue Sep 10, 2018 · 5 comments

Comments

@spoldman
Copy link

I have a repository that is getting packages from a monorepo and those packages depend on each other. But no matter what I do I'm not able to use linklocal to link those subpackages of the package that I'm importing.

Here is an example:

MainApp dependencies
-> packageA

packageA dependencies :
-> packageB

if I run the following inside the MainApp only node_modules/packageA gets linked not node_modules/packageB
linklocal --named packageA packageB

If I run it with the recursive flag it only links the node_modules/packageA/node_modules/packageB not node_modules/packageB

Should it not also link packageB when the recursive flag is set?

spoldman added a commit to spoldman/linklocal that referenced this issue Sep 11, 2018
spoldman added a commit to spoldman/linklocal that referenced this issue Sep 11, 2018
@spoldman
Copy link
Author

This might have something to do with how yarn does workspaces. That the shared dependency is placed in the root folder instead of having them in the linked package. Just a wild guess.

@timoxley
Copy link
Owner

@spoldman can you set a test repo or give some step-by-step instructions so I can reproduce this?

@timoxley
Copy link
Owner

timoxley commented Sep 12, 2018

@spoldman I re-read your question and I believe this is actually expected/correct behaviour. linklocal will only link the dependencies specified in package.json, it doesn't do any form of hoisting, and shouldn't need to if your dependencies are all explicitly specified.

If I understand correctly, you must be trying to require('packageB') from the top level, or from some other package that doesn't have packageB listed as a package.json dependency?

You probably shouldn't expect to be able to require anything that isn't explicitly defined in the current package.json. That you can require sub-dependencies after a regular npm install is an artifact of npm's hoisting algorithm, which is more of an optimisation/implementation detail rather than a feature that should be exploited by user code.

It's entirely possible that in the future the hoisting algorithm will determine that a sub-dependency can no longer be hoisted, or perhaps an update to the package(s) that dependency is hoisted out of no longer depend on it, and mysteriously your app will no longer be able to require that particular dependency.

In other words, anything that requires on packageB should explicitly define packageB as a dependency in its closest package.json – the same goes for everything you're requiring.

If you add packageB to your top level package.json, and/or to whichever packages depend on packageB, I believe that will have the effect you're after, without needing to add any special-case behaviour to linklocal. Please try this and let me know if this solves your issue, I may have misunderstood.

@spoldman
Copy link
Author

I created a test repo: https://github.com/spoldman/linklocal-test and I think this is a Yarn only issue. Because everything works fine with NPM. Looks like Yarn puts package-b inside the MainApp/node_modules folder but npm does not. I tested both using workspaces and not and both cases resulted in yarn putting package-b inside MainApp/node_modules folder.

MainApp/node_modules
image

Steps to reproduce

./packages run: yarn install
./MainApp run: yarn install
./MainApp run: linklocal -r --named package-a package-b ../packages/libs

Notice that only package-a get liked inside MainApp/node_modules

I'm using Yarn 1.9.4

@spoldman
Copy link
Author

@timoxley have you had time to look at the test repo I sent?

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

No branches or pull requests

2 participants