Workspaces - Is it possible to exclude some node_modules from beeing hoisted to the root node_modules folder?

[thomasfr]

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

What is the current behavior?
We are currently using hoist feature from lerna. I tried to move to yarn workspaces and it works way faster! Awesome, thank you!

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

What is the expected behavior?
But i also need the ability (sadly) to exclude some node_modules from not beeing hoisted to the root node_modules folder but be physically installed in the package i configured it as dependency. (The same way the --no-hoist arguments are working for lerna. )
The reason is, sadly, that some dependencies we use, are trying to require some dependencies with an absolute path from packages/<package>/node_modules directly. So i have to exclude some.
Is there a way to configure some sort of exclude glob for workspaces?

Please mention your node.js, yarn and operating system version.
yarn --version: 0.27.5
node -v: v6.11.0
macOS: 10.12.5

[BYK]

@thomaschaaf is this a feature request? :) (since you haven't mentioned that in the first question)

[BYK]

//cc @bestander

[thomasfr]

@BYK If its not yet possible (maybe it is not documented?) than it is a feature request.

[bestander]

Would a symlink to the hoisted location work?

[thomasfr]

lerna installs it directly when using --no-hoist. But i think a symlink should also work, i can try that out later. I will let you know

[seansfkelley]

Another use-case for disabling hoisting is that it helps prevent devs from creating accidentally-malformed packages.

I worked on a Lerna repo that had hoisting enabled. A number of the packages were erroneously using hoisted dependencies they had not specified because the code compiled/ran fine due to the way in which Node searches for modules -- namely, by traversing up the file hierarchy until it finds something in any ancestor's node_modules with the right name. In turn, this meant that packages would be published broken, because consumers wouldn't have the complete, true list of dependencies at install time.

For our use-case, hoisting bought us nothing while introducing more pitfalls, so I would love a way to disable hoisting on any given monorepo -- indeed, I would actually argue that no-hoist should be the default for the reasons stated above and by the principle of least surprise.

[bestander]

All good points here.
We can discuss whether the no-hoist should be default later.
For now I can't dedicate enough time to work on this feature and help is needed.

The hoisting logic is isolated in https://github.com/yarnpkg/yarn/blob/master/src/package-hoister.js and you know whether the dependency is a workspaces if it's name is workspaceLayout.virtualManifestName.
Send a PR

[connectdotz]

we bump into this issue with react-native so working on this PR. Question regarding the preference of where to put the nohoist configuration. A few options to consider:

1. put it in projects.json, like the workspaces, create a top-level nohoist:[] property
2. put it in projects.json, but create a new namespace, such as yarn or workspaces, and put all workspaces related info there, including nohoist.
3. put it in .yarnrc (not sure about this because it seems .yarnrc is for yarn itself, but leave it here for completion)

Let me know if you see other better options, right now we are leaning toward option 2, suggestion something like this:

//package.json
workspace: {
    workspaces:[],
    nohoist:[]
}

thoughts?