error Bad hash installing git+https dependency by branch

[ericgundrum]

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

bug

What is the current behavior?

error Bad hash.

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

git clone https://github.com/ericgundrum/pouch-websocket-sync-example.git -b yarn-failure yarn-test
cd yarn-test
rm yarn.lock
yarn cache clean
yarn install

(The relevant repo snapshot is a0aac3d.)

What is the expected behavior?

Install all dependencies.

Please mention your node.js, yarn and operating system version.
macOS 10.10.5
node v7.9.0
yarn v0.23.4
yarn v0.24.0-20170502.1431 also fails
yarn v0.23.0-20170331.1019 also fails
yarn v0.23.0-20170327.1305 suceeds

Note package.json line 23 specifies a git+https url with a branch label.
Changing the label to a commit hash avoids the failure.

My 'yarn config' might matter; I use yarn-offline-mirror

info yarn config
{ 'version-tag-prefix': 'v',
  'version-git-tag': true,
  'version-git-sign': false,
  'version-git-message': 'v%s',
  'init-version': '1.0.0',
  'init-license': 'MIT',
  'save-prefix': false,
  'ignore-scripts': false,
  'ignore-optional': true,
  registry: 'https://registry.yarnpkg.com',
  'strict-ssl': true,
  'user-agent': 'yarn/0.23.4 npm/? node/v7.9.0 darwin x64',
  lastUpdateCheck: 1493783586093,
  'yarn-offline-mirror': _valid local path_ }

[ericgundrum]

Possibly this is related to #3198 and #1916.

[ericgundrum]

I can use an older yarn to build yarn.lock, then yarn install works with newer versions. Presumably the resolved pouch-remote-stream line in yarn.lock enables the code to bypass the failing hash check.

[ghost]

I've encountered the same problem today.

The yarn.lock file resolves the branch/version entry to the commit hash of the target git repo and creates a zipped file within the offline mirror folder.
After cleaning the cache and trying to reinstall (from the offline mirror), yarn compares the commit hash of this entry with the file hash of the created zip file in the offline mirror folder, which is why it fails.

Unfortunatly, I was not able to work around this problem yet, so I dumped the offline mirror for the time being.

[tomoguisuru]

I am also seeing this same behavior with Yarn 0.23.2

[mltel]

I am also seeing this issue with Yarn v0.23.4

[chr1shaefn3r]

I am also seeing this issue with Yarn v0.24.5

[nmanoogian]

I am also, also seeing this on Yarn v0.24.5.

If you'd like a terrible terrible workaround, I found one. Change the hash in your yarn.lock and your offline mirror filename to match what yarn in expecting (the sha hash of the tarball). If everything matches up, yarn will install from the tarball without inspecting the fake git hash.

[ericgundrum]

The breaking change occurred in eac1836. The prior commit, 9a743d7, does not exhibit the failure.

I haven't yet found what part of eac1836 causes the problem.

[ericgundrum]

The error message's expected hash actually matches the git commit hash. The GitFetcher.hash property appears to be initialized with the commit hash. Then fetchFromLocal() compares this to the tarball hash and rejects it. But, the older code seems to do the same. The intent of the new codes looks to be removing the mirror tarball resolved pathname returned by the fetcher.

For the older code to work, something would have to set the GitFetcher.hash property to the tarball hash -- possibly extracting it from the resolved line of yarn.lock and feeding it into GitFetcher.hash. I've yet to find the code which does this.

[nuzz]

I think I'm hitting this condition while trying to build an application offline (with npm cache) which includes plotly. Plotly (and its dependencies) fail here.

[BYK]

Couldn't reproduce with 0.24.6 or latest master with the provided steps (with or without the yarn config)

[BYK]

@ericgundrum - Can you confirm that this is resolved on master at least? (or update the instructions so I/we can repro)

[ericgundrum]

@BYK - I am not able to reproduce this issue using 0.24.6.

The git repo dependency is no longer being stored in the offline mirror cache, but I see from #3449 that is intentional. Hopefully that will change when #3449 is resolved.

Otherwise this looks good to me.

[arcanis]

@ericgundrum What do you mean, the git repo dependency is no longer being stored in the offline cache? It should - the only change in #3449 is that it disables the hash check, since we're currently storing inadequate data in our lockfile when it comes to git repos.

This issue should be resolved, going to close it 👍 Next step will be to move the hash into an external field, but that's another task.

[ericgundrum]

@arcanis To test this in the yarn-test repo created above, I perform these steps within yarn-test/

0. yarn config list shows 'yarn-offline-mirror': '/Users/eric/vault/annex/yarn-cache'
1. ls -l ~/vault/annex/yarn-cache/pouch-remote-stream* to confirm the dependency is not in the mirror
2. rm -rf yarn.lock node_modules/
3. yarn install
4. ls -l ~/vault/annex/yarn-cache/pouch-remote-stream* to confirm the dependency is not added to the mirror

Am I wrong to expect yarn install to populate the offline mirror when running yarn 0.24.6?