[feature] hint hoister algorithm

[bestander]

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

What is the current behavior?

Yarn hoists dependencies consistently but sometimes unpredictable.
A very common version of a package (core-js@2) can fail to hoist on top of node_modules tree if a less common package (core-js@1) got hoisted there first.

What is the expected behavior?

• Yarn can indicate that a dependency is getting hoisted too many times.
• Yarn can indicate how to fix package.json so that we get optimised hoisting
• package.json/.yarnrc can have hints for package-hoister to use as priorities

[Daniel15]

Shouldn't Yarn be able to solve this by hoisting the "most popular" version of a package? How does it determine the version to hoist at the moment?

[ljharb]

That's tricky tho, because what defines "most popular" - semver-latest? "latest" dist-tag on npm? most downloads reported on the registry? most packages requiring it in the current tree?

[Daniel15]

most packages requiring it in the current tree?

Sorry, I should have clarified. This is what I meant - relative popularity. If 10 dependencies/packages depend on core-js@2 and only one package depends on core-js@1, then core-js@2 should be the one that's hoisted.

[ljharb]

Makes sense - what would be the deterministic tiebreaker?

[Daniel15]

what would be the deterministic tiebreaker?

You mean if, for example, 5 packages depend on core-js@1 and 5 packages also depend on core-js@2? In that case, I think we should hoist the newest version.

[gaearon]

Just a heads-up we plan to disable Create React App Yarn integration because of this.

[benjaminapetersen]

+1 for this! I just tried yarn for the first time, doing a simple 'hello world' install to play with react. Side by side, yarn & npm:

• 131MB install to node_modules via nmp install
• 556MB install to node_modules via yarn install

Over half a gig worth of dependencies was quite a surprise. That said, it still looks like yarn is bringing some excellent features to the table!

[hpurmann]

Isn't this fixed by #2676?

[farhan711]

Yes Isn't fixed by #2676

[bestander]

#2676 gives an acceptable hoisting structure for most cases based on how often a dependency would be repeated if installed without hoisting.
This feature request could address some edge cases where developers might want to override that logic.

I'd say this is now a low priority until we see some real life examples where it would help.
I don't think anyone is focusing on it currently, so anyone is welcome to claim and implement it