yarn creates unnecessary dupe(s)

[akomm]

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

Bug

What is the current behavior?

yarn installs dupe for vendor dependency, even though its satisfied by an explicit root dependency.

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

• mkdir test && cd test
• yarn init (defaults)
• yarn add @types/react-relay@^1.3.12 @types/relay-runtime@^1.3.12

What is the expected behavior?

• @types/react-relay@^1.3.12 and @types/relay-runtime@^1.3.12 packages installed
• @types/react-relay@^1.3.12 does not have a node_modules/@types/[email protected](*) dupe (it has dependency on @types/relay-runtime@*, which is satisfied by the ^1.3.12 explicitly installed)

It would make sense and its what npm does for example.

(*) currently its 5.0.0, but it might change if newer versions are release. Its a bit weird configured in regards to dependency on the package maintainer side, I already issued this, but also yarn makes unnecessary dupe.

Please mention your node.js, yarn and operating system version.
yarn: 1.16.0
node: 10.1.0
ubuntu 16.04

[DanielRuf]

yarn: 1.9.4

Hi @akomm,

did you already try to upgrade Yarn to the latest release 1.16.0?

[akomm]

@DanielRuf tested it now. Same behavior.

[DanielRuf]

Did you delte node_modules and yarn.lock?

Ok, then please update the version in your issue description.

[akomm]

@DanielRuf

I did it multiple times during reproduction.

And also in my reproduction steps above there is a blank new project with no lock and node_modules and still the dupe is created.

To be sure, I did it now again, with @types/relay-runtime@^1.3.12 and @types/react-relay@^1.3.12 in package.json devDependencies (dependencies = same behavior).

removed yarn.lock & node_modules, yarn install

dupe is there.

I did the blank project example to reproduce and to prevent some other causes for the dupe, so only the two packages affected are there.

[DanielRuf]

Ok, thanks for the clarification.

[akomm]

Just a note:

This is probably a major issue for people who use typescript and require @types/* packages from DT.

From one of Collaborator's: those package's dependencies are auto-generated with *-version constraint and they can do nothing about it right now.

For those who encouter this issue, it blocks the code from being compiled and type-checked properly. Seems like a small issue, might get really annoying.

I was looking for solutions, similar to composer aliasing (php's package manager) and found this:
https://yarnpkg.com/lang/en/docs/selective-version-resolutions/

And could workaround the issue until it is fixed by adding this section into my package.json:

{
    "resolutions": {
        "@types/relay-runtime": "^1.3.12"
    }
}

Hope it helps those with the same issue.

[merceyz]

Closing as working as intended, * is treated as anything goes which currently maps to latest

[akomm]

I don't think you've thought through this deeply enough. Neither the logic, nor the consequences of what you are saying.

• There is no logical reason to create a package dupe when the dependency is already satisfied.
• Dupes generate warnings. While warnings can probably be ignored, its not the intent of warnings to be noise that you are supposed to ignore. But you are conditioning people to do exact that, because this sort of non-sense is not fixable. So every package yarn decides to needlessly dupe will generate more and more noise...
• To name an example, thousands of packages on DefinitelyTyped have deps set as "*". The actual version you want you need to define in root. To get two packages of typings for same source is a big issue, because two packages define types for the same namespaces/symbols, thankts to yarn's needless duping. So yes, you could gently tell the DT users to FO, or you could just stop pointlessly duping packages. What do you think?

[merceyz]

I'll just point you to #3951 (comment)

[akomm]

Which changes exactly nothing. The argument is, we don't to fix the errors of others (DT maintainers in this case). I don't ask you to fix errors of DT maintainers. I ask you to stop duping for no freaking reason. Does this make sense?

BTW, the claim in this comment is very funny, just a sum up: "if we start fixing others mistake, and other package manager also do this but differently, we would end up in a big mess".

Wow. This is so wrong. This is the behavior of all package manager I'm aware of, also from other languages: if a constraint is satisfied commonly, its used. How did that turn out to be solved differently on all package managers? Shouldn't there be chaos? Or maybe the outcome is the same, independently, because it freaking makes sense only that way?

Likewise, DT is pig-headed. They set dependency as *, which is bonkers. If I don't explicitly set dependencies they have (which I shouldn't, unless its peer), the code will break later. Totally missed the point of package managers and dependency definition concept. A big issue as well.

However it does not excuse stupid behavior on yarn side, because it could fix someones mistake, if it did behave differently. What kind of logic is that?

[arcanis]

Hey @akomm. Let me be clear on a few points:

• Coming on a repository and telling its maintainers that "[you] don't think [they]'ve thought through this deeply enough" is quite entitled. Especially when it takes one search to find threads about this exact problem. Seriously, I wrote more than 15k words on this, all threads considered, I'm sure you could have found a few of them.

• The point I made isn't "we can't do better", it's "perhaps we could do better, but it would involve significant resources for what would still be an unsatisfying result, and we have better things to do." I understand you're not familiar with how package managers are implemented, so perhaps you should give us the benefit of the doubt and listen to us? Of course you can try implementing a fix yourself, it might be a good learning experience.

I'll lock this thread since you've made your point clear (in a fairly rude way), and I don't think there's really anything to add.