yarn cache for "yarn add <tarball>" is caching package version rather than URL.

[jordanburke]

We create and use an internal package library which is tarballed and placed on a server as part of the builds. Since this a built package off of continuous builds, we do not always increment the version. Instead we put part of the commit hash into the file name for retrieval via npm install.

Since trying out yarn (which works great) - we've run into an issue with this lib. It seems the first time it encounters the tarball it fetches the correct version, however once we change the URL to a more current version in the package like so:

"internal-lib": "http://server.local/packages/internal-lib.v9.1.1-b0e81daa.tar.gz",

to:

"internal-lib": "http://server.local/packages/internal-lib.v9.1.1-70126d8f.tar.gz",

Running yarn install, or yarn even yarn add http://server.local/packages/internal-lib.v9.1.1-70126d8f.tar.gz (we've tried --exact as well) does not or will not grab the newer file from the updated URL.

However once I run:

yarn cache clean

The correct file will be retrieved. In cases where caching is occurring the yarn.lock file will be updated with the newer URL, but just not the content. I know ideally the package.json should be updated in cases of libs, but sometimes that's not the case and changing the URL one would expect a different file to be retrieved.

[skhavari]

You can see this in action if you try to fetch different versions of facebook/draft-js. The following will not do what I think most people would expect

Add published draft-js

yarn add draft-js

This grabs version 0.9.1 published to NPM

Grab the latest stable

yarn add https://github.com/facebook/draft-js.git#0.9-stable

yarn uses the npm published version since the version published to npm and the version in the repo both have version 0.9.1.

Workaround is to blow away the cached version before adding.

[simonihmig]

Seeing the same thing. Targeting a github branch like master, and having yarn.lock reference the correct commit hash, still install a previously cached stale version (obviously not matching the git commit hash) with the same package.json version. Breaks the promise of yarn having deterministic installs, so should be given high priority IMHO.

[scothis]

Breaks the promise of yarn having deterministic installs

This situation is even worse when a the same package at a different commit/branch is referenced by a nested dependency. Even with a clean cache it's not predictable which version will be installed.

[bestander]

Should be fixed now #2074