When downloading 2 versions of Cypress simultaneously, one clobbers the other resulting in nondescript error and exit

Current behavior:

We recently encountered an error on one of our repos ourselves where we use yarn. The problem was that we were downloading two versions of cypress within our package.json. We run a monorepo, so one of the cypress versions was in the main package.json and the other cypress version was in a sub-module of our monorepo.

Since we save cypress upon download to /tmp/cypress.zip, they were clobbering each other when both were being downloaded/unzipping at the same time. Due to how yarn works, this is likely to exhibit more frequently in it - although it’s still possible using npm.

Note: This can still happen even if the 2 Cypress versions are the same version number

Basically:

• Version 1 and 2 of Cypress begin download
• Version 1 of Cypress finishes download
• Version 2 of Cypress is still downloading - deleting current /tmp/cypress.zip
• Version 1 of Cypress begins unzipping /tmp/cypress.zip
• Error

Resulting in this error specifically:

Installing Cypress (version: 3.3.2)

[04:46:10]  Downloading Cypress     [started]
[04:46:11]  Downloading Cypress     [completed]
[04:46:11]  Unzipping Cypress       [started]
read err Error: not enough bytes in the stream. expected 8709456. got only 2882632
    at AssertByteCountStream._flush (/root/monorepo/node_modules/yauzl/index.js:494:15)
    at AssertByteCountStream.prefinish (_stream_transform.js:141:10)
    at AssertByteCountStream.emit (events.js:198:13)
    at prefinish (_stream_writable.js:635:14)
    at finishMaybe (_stream_writable.js:643:5)
    at endWritable (_stream_writable.js:663:3)
    at AssertByteCountStream.Writable.end (_stream_writable.js:594:5)
    at InflateRaw.onend (_stream_readable.js:655:10)
    at Object.onceWrapper (events.js:286:20)
    at InflateRaw.emit (events.js:203:15)
    at endReadableNT (_stream_readable.js:1129:12)
    at process._tickCallback (internal/process/next_tick.js:63:19)
events.js:174
      throw er; // Unhandled 'error' event
      ^

Error: invalid central directory file header signature: 0x98d05ebb
    at /root/monorepo/node_modules/cypress/node_modules/yauzl/index.js:258:70
    at /root/monorepo/node_modules/cypress/node_modules/yauzl/index.js:631:5
    at /root/monorepo/node_modules/cypress/node_modules/fd-slicer/index.js:32:7
    at FSReqWrap.wrapper [as oncomplete] (fs.js:467:17)
Emitted 'error' event at:
    at emitError (/root/monorepo/node_modules/cypress/node_modules/yauzl/index.js:232:8)
    at emitErrorAndAutoClose (/root/monorepo/node_modules/cypress/node_modules/yauzl/index.js:227:3)
    at /root/monorepo/node_modules/cypress/node_modules/yauzl/index.js:258:42
    at /root/monorepo/node_modules/cypress/node_modules/yauzl/index.js:631:5
    at /root/monorepo/node_modules/cypress/node_modules/fd-slicer/index.js:32:7
    at FSReqWrap.wrapper [as oncomplete] (fs.js:467:17)
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
Exited with code 1

See https://github.com/cypress-io/cypress/issues/3515#issuecomment-506614578

Desired behavior:

When downloading Cypress, we need to make the tmp destination more unique like:

/tmp/cypress-${version}-${random}.zip

Steps to reproduce: (app code and test code)

project/packages/foo/package.json

{
  "name": "foo",
  "devDependencies": {
    "cypress": "3.3.2"
  }
}

project/packages/bar/package.json

{
  "name": "bar",
  "devDependencies": {
    "cypress": "3.3.2"
  }
}

Run yarn

Versions

Cypress 3.3.2

[wmartins]

Ran into the same issue when setting up a monorepo strategy in one of my company’s project.

In fact, in my case, the problem doesn’t occur as specified by @jennifer-shehane. In my case, it only occurs because I’m installing two different versions of Cypress (3.3.2 and 3.4.0 in my tests here).

So, I think some things can help out yarn monorepo users:

• Try to “align” your Cypress versions in all packages in your monorepo (which may be challenging)
• If you want a quick fix, you can set CHILD_CONCURRENCY to 1. This will download Cypress sequentially, which may slow down your build, but at least it will not fail when installing Cypress

In my case, I changed my testing strategy to centralize e2e tests into a single place instead of having it divided by package. It was a possibility in my case.

[krokofant]

I worked around this by setting env var CYPRESS_INSTALL_BINARY to 0 to skip downloading the cypress binary while installing packages, and then running yarn cypress install to install the cypress binary.