Yarn integrity check fails for classnames

[Prior99]

Oni Version: master Neovim Version (Linux only): 0.3.2 Node version: 10.9.0 Yarn version: 1.10.1 Operating System: Arch Linux

Issue:

When performing a yarn install, the integrity check for classnames fails:

error https://codeload.github.com/JedWatson/classnames/tar.gz/34a05a53d31d35879ec7088949ae5a1b2224043a: Integrity check failed for "classnames" (computed integrity doesn't match our records, got "sha1-3F1IwI7v/EQGECc2RX2sInPW44k=")

I found the following lines in the yarn.lock file:

classnames@^2.2.3, classnames@^2.2.5:
  version "2.2.5"
  resolved "https://codeload.github.com/JedWatson/classnames/tar.gz/34a05a53d31d35879ec7088949ae5a1b2224043a"

classnames is the only dependency istalled from codeload.github.com. Is that correct? Why is that so?

Expected behavior:

yarn install passes.

Actual behavior:

yarn install fails with above error.

Steps to reproduce:

1. Clone repository
2. yarn install

[bryphe]

Thanks for logging the issue & details @Prior99 !

We hit this in automation too - downgrading to an earlier version of yarn 'fixed' this for us - but a better fix would be to correct the dependency. The codeload URL doesn't look right to me. I wonder if we can manually edit the lockfile to fix this?

[Prior99]

I'd just delete the lines from the lockfile and simply add the dependency again. I can submit a PR if you like.

[akinsho]

@Prior99 @bryphe I think with the refactor of some of the components to styled-components I think we don't actually use classnames in the project anymore so this might be able to be resolved by removing the dependency all together

[bryphe]

I'd just delete the lines from the lockfile and simply add the dependency again. I can submit a PR if you like.

That sounds great! Thanks @Prior99 .

@Prior99 @bryphe I think with the refactor of some of the components to styled-components I think we don't actually use classnames in the project anymore so this might be able to be resolved by removing the dependency all together

classnames is actually a transitive dependency - meaning we don't include it in our package.json, but it's a downstream dependency of a package we depend on. Yarn has a useful command yarn why - this is the output for classnames:

E:\oni [(v0.3.7-beta2)]> yarn why classnames
yarn why v1.10.1
warning ..\package.json: No license field
[1/4] Why do we have the module "classnames"...?
[2/4] Initialising dependency graph...
[3/4] Finding dependency...
[4/4] Calculating file sizes...
=> Found "classnames@2.2.5"
info Reasons this module exists
   - "react-virtualized" depends on it
   - Hoisted from "react-virtualized#classnames"
   - Hoisted from "react-transition-group#classnames"
Done in 16.54s.

(So it's needed by react-virtualized & react-transition-group)