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

Should apply version conflict resolution before determining licenses #2018

Closed
sschuberth opened this issue Nov 24, 2016 · 2 comments
Closed

Comments

@sschuberth
Copy link

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

To me this is a bug, although a cunning person might argue it's a missing feature ;-)

What is the current behavior?

Currently, the yarn licenses commands list are based on a flat list of all transitive dependencies before any version conflict resolution is applied. This means that the same package might appear in different versions. In our concrete case we have e.g.

├─ [email protected]
│ ├─ License: MIT
│ └─ URL: git://github.com/substack/minimist.git
├─ [email protected]
│ ├─ License: MIT
│ └─ URL: git://github.com/substack/minimist.git
├─ [email protected]
│ ├─ License: MIT
│ └─ URL: git://github.com/substack/minimist.git

The issue with this is that packages might (and actually do) change their license between versions, resulting in potential over-reporting / false positives.

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

Run yarn licenses ls e.g. on https://github.com/heremaps/map-linkbuilder-app.

What is the expected behavior?

Each used package should be listed only once in exactly the version being used after version conflict resolution has been applied.

Please mention your node.js, yarn and operating system version.

Yarn 0.17.7 on Windows 8.1 x64.

@sschuberth
Copy link
Author

By reading this answer, I just noticed my request might actually be invalid. Coming from the JVM world I assumed that some version conflict resolution would be done by the Node.js dependency manager (npm or yarn), but that does not seem to be the case as multiple versions can be used in parallel. I was misled by this issue talking about a "version conflict strategy", but that's not about picking one version, but about organizing all used versions in a smarter way.

@olingern
Copy link
Contributor

Closing this. If this is is still an issue on 1.21.1, please comment and I'll reopen.

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

4 participants