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

Package version resolve from registry is not deterministic #3466

Closed
blexrob opened this issue May 22, 2017 · 1 comment · Fixed by #3477
Closed

Package version resolve from registry is not deterministic #3466

blexrob opened this issue May 22, 2017 · 1 comment · Fixed by #3477

Comments

@blexrob
Copy link
Contributor

blexrob commented May 22, 2017

This issue is a bug.

** Summary **

The package version resolving mechanism (resolving a pattern to a actual version) in package-request/package-resolver.js is not deterministic. Specifically, the order of the responses to version request can influence the resolving of a pattern.

** Analysis **

In package-request.js, the following code (in find) is relevant:

    const resolved: ?Manifest = this.resolver.getHighestRangeVersionMatch(name, range);
    if (resolved) {
      this.reportResolvedRangeMatch(info, resolved);

Let's say we have a package X with three requested patterns:
A. [email protected]
B. X@^1.0.0
C. [email protected]

If the version requests come back in order ABC, the following happens:

  1. A resolves to version 1.1.0, and is stored in the requester.
  2. B resolves to 1.2.0, but is also a match with 1.1.0, so 1.1.0 is used.
  3. C resolves to 1.2.0, not a match with 1.2.0, so 1.2.0 is used and stored.

But, if the versions requests resolve in order ACB, the following happens:

  1. A resolves to version 1.1.0, and is stored in the requester.
  2. C resolves to 1.2.0, not a match with 1.2.0, so 1.2.0 is used and stored.
  3. B resolves to 1.2.0, which is also the highest match in the resolver.

So, depending on the order of the package version resolves, the resolved version can change.
(in this case, ^1.0.0 can resolve to either 1.1.0 or 1.2.0)

Repro:
Create the following package.json

{ "dependencies": {
     "graceful-fs": "4.1.10",
     "write-file-atomic": "1.3.4",
     "path-type": "1.1.0"
     }
}

and run the following command several times:

rm -rf node_modules/ yarn.lock ; /opt/src/yarn/bin/yarn && /opt/src/yarn/bin/yarn check

Sometimes yarn check will report errors, if the resolver got different versions for graceful-fs than the previous yarn run (requested versions: '4.1.10', '^4.1.2' and '4.1.11').

Versions:
Fedora 25
Node 7.10.0
yarn: git commit 67fe99, from 20170519

@bestander
Copy link
Member

Thanks for the steps and analysis!
This is a hi pri issue, we need to sort it out ASAP.
Anyone wants to help?

blexrob added a commit to blexrob/yarn that referenced this issue May 22, 2017
blexrob added a commit to blexrob/yarn that referenced this issue May 22, 2017
bestander added a commit to bestander/yarn that referenced this issue Jun 2, 2017
… versions are known. Fixes yarnpkg#3466 (yarnpkg#3477)"

This reverts commit a080a83.

The solution was still not deterministic enough (see discussion) and test was not failing before the change reliably.
Next commit comes up with a solution.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants