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

Transitive wildcard dependencies should use existing versions if possible #4136

Closed
glentakahashi opened this issue Aug 10, 2017 · 5 comments
Closed

Comments

@glentakahashi
Copy link

glentakahashi commented Aug 10, 2017

Basically an extension of #2763

When packages declare dependencies using wildcards, existing version should be re-used if possible for consistency's sake. For example:

My package.json:

"@types/react": "^15.0.3",
"@types/react-redux": "^4.4.34"

@types/react-redux depends on "@types/react": "*"

In my yarn.lock:

"@types/react@*":
  version "16.0.2"
  resolved "https://registry.yarnpkg.com/@types/react/-/react-16.0.2.tgz#0b31a73cdde6272b719e5b05a7df6d1e2654a804"

"@types/react@^15.0.3":
  version "15.6.1"
  resolved "https://registry.yarnpkg.com/@types/react/-/react-15.6.1.tgz#497f7228762da4432e335957cb34fe9b40f150ae"

In this case, I think @types/react-redux should use 15.6.1 because it's specified by the package.json. For other example, such as dependencies using ^15.6, and package.json using ~15, they should both use 15.6.1.

EDIT: I now realize I can use --flat to force this with the resolutions block, but it seems strange to me that this isn't the default. If packages properly declare their dependencies, it shouldn't matter which version the have installed, so it seems ideal to always use package.json version if possible.

Also, --flat requires you to resolve /all/ dependencies which is just impossible for most repos.

@glentakahashi
Copy link
Author

Actually seems like a regression from #1158

Yarn version: 0.27.5
Node version: 7.6.0

@glentakahashi
Copy link
Author

glentakahashi commented Aug 10, 2017

Upon further investigation, seems like a bug in the package resolver and how it handles "*". If I manually set solvedRange to be * and also manually set info.fresh to be true, I get the behavior I expect as described above.

https://github.com/yarnpkg/yarn/blob/master/src/package-request.js#L265

The current behavior seems to be: if two packages have compatible (but possibly different, e.g. ^5.0.1, ^5.0.0) and valid semverRanges, then the resolved version for both (possibly 5.2.3 in my example) should match and the call to "getExactVersionMatch" will work properly. If the versions don't match, or for example, the package is added to an existing yarn.lock file (with version being something like 5.2.1), then the getHighestRangeVersionMatch will search for existing saved versions and resolve the highest one correctly together.

In both these scenarios, it seems that it doesn't work for * or ~. Not sure if this is expected

@glentakahashi
Copy link
Author

This is also related to DefinitelyTyped/DefinitelyTyped#18708

@BYK
Copy link
Member

BYK commented Aug 15, 2017

The current behavior is not a bug. It is "legal" to resolve these two separately and here's what happens: the * dependency is resolved first, which resolves to latest without any other constraints, then the top-level one is resolved to the required version which is not the latest. Thus, yarn installs them separately.

To get a single one, @types/react-redux needs to define @types/react as a peerDependency not a normal dependency. We'll look into optimizing this a bit more, but as stated earlier, this is not a bug and is a normal occurrence.

@glentakahashi
Copy link
Author

Closing as duplicate of #3951 and tracking a fix in microsoft/types-publisher#366

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