I have a repo with Jest v25.4.0 installed, and all tests are passing. If I clone that repo at a new location, npm install, and run my tests, one of my suites fails. I ran npx jest --version in both locations, and was surprised that the output versions were different: v25.4.0 in the original clone, and v25.5.4 in the new clone. For what it is worth, jest is _not_ installed globally.
I deleted node_modules directory and package-lock.json from the new clone, removed jest from package.json dependencies, ran npm install, followed by npm install -D [email protected] to _ensure_ that version 25.4.0 was installed. npx jest --version still output v25.5.4. I then checked node_modules/jest/package.json and it contains the correct version number 25.4.0. _However_, node_modules/@jest/core/package.json shows a version number of 25.5.4.
I repeated the above process with versions 25.3.0 and 25.2.0, with the exact same outcome: failing tests and incorrect version of @jest/core. I'm not sure when the regression was introduced, or what changes are making my tests fail, but I do know that everything was working properly when 25.4.0 was the latest release.
As an aside, this:
npm i -D [email protected]
npx jest --version
outputs: 24.9.0, so the issue may have been around for awhile.
Worked up to version: 25.4.0
Stopped working in version: unknown
npm init -y
npm install -D [email protected]
npx jest --version
I expected jest v25.4.0 to be installed
Repl.it will not allow the install of previous package versions.
npx envinfo --preset jest$ npx envinfo --preset jest
npx: installed 1 in 0.649s
System:
OS: Linux 5.6 Fedora 31 (Workstation Edition) 31 (Workstation Edition)
CPU: (4) x64 Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz
Binaries:
Node: 14.1.0 - /usr/bin/node
npm: 6.14.4 - /usr/bin/npm
npmPackages:
jest: 25.4.0 => 25.4.0
This is expected since we use semver ranges for our own packages. We can consider using exact versions of our own packages for Jest 26
I feel that the issue with using ranges is that, if you push a bug to a package that is depended on, it breaks every prior version in the semver major range of the main package with no recourse. It also means you can only ever install the latest version from each semver major range. It doesn't seem unrealistic for an end-user to expect npm install [email protected] to install version "x.y.z" _exactly_ (and Jest even appears to do so, as the installed node_modules/jest version _is_ correct).
Since I cannot install version 25.4.0 anymore, I'm going to have to either figure out what is causing Jest to fail, or downgrade to the latest version of the 24 branch. I am fairly certain it has something to do with the new work on ESM, but I don't really have the time to dig through the latest changes to Jest at the moment.
Since the root of my need to revert to an older version is related to Jest failing previously good tests, here is a Repl.it demonstrating that issue. I know you've been doing a lot of work on ESM compatibility in Jest, so perhaps you have some insight as to why this is failing, even though there are no ES modules present, and the code works in production.
Most helpful comment
I feel that the issue with using ranges is that, if you push a bug to a package that is depended on, it breaks every prior version in the semver major range of the main package with no recourse. It also means you can only ever install the latest version from each semver major range. It doesn't seem unrealistic for an end-user to expect
npm install [email protected]to install version "x.y.z" _exactly_ (and Jest even appears to do so, as the installednode_modules/jestversion _is_ correct).Since I cannot install version 25.4.0 anymore, I'm going to have to either figure out what is causing Jest to fail, or downgrade to the latest version of the 24 branch. I am fairly certain it has something to do with the new work on ESM, but I don't really have the time to dig through the latest changes to Jest at the moment.