Use strict versions for internal depedencies

[alexandernanberg]

🐛 Bug Report

Jest currently uses ^ for all it's internal dependencies which causes issues if there is a bug in a minor/patch release and you want to revert.

E.g. jest has a dependency on @jest/core ^26.5.3, so installing from scratch without a lockfile isn't deterministic if you are using an outdated version of jest.

Most of this can be solved by a lockfile but then you can't refresh the lockfile for other dependencies.

To Reproduce

Steps to reproduce the behavior:

• Install jest@26.5.3
• Open yarn.lock and see that @jest/core@26.6.1 was installed

Expected behavior

I think it would be reasonable if the internal packages would use strict versions, e.g @jest/core 26.5.3 instead of @jest/core ^26.5.3

Which results in the consumer's desired version being installed

Link to repl or repo (highly encouraged)

N/A

envinfo

  System:
    OS: macOS 10.15.7
    CPU: (16) x64 Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
  Binaries:
    Node: 12.19.0 - ~/.nvm/versions/node/v12.19.0/bin/node
    Yarn: 1.22.5 - /usr/local/bin/yarn
    npm: 6.14.8 - ~/.nvm/versions/node/v12.19.0/bin/npm

[SimenB]

Yep, this is actually a change I was planning to make for Jest 27 🙂 Haven't discussed it with the team yet, tho.

@jeysal @thymikee thoughts?

[thymikee]

Lerna bumps deps in package.json in sync with the real ones, so whenever a user upgrades jest, our transitive dependencies will be updated as well and reflected in the lock file. I'm in favor of this.

[jeysal]

I'm not convinced. If it were 26.x.x i.e. any version of the same major, including lower versions, that would of course be a problem since you may be missing out on new features (and also it'd sometimes just break since Jest packages depend on new features in other Jest packages), but allowing higher versions seems okay to me.
I'm aware locking the version of the packages will usually only force duplication if someone else also does (or wants at least a higher version, e.g. jest and all deps are locked at 27.1.2 and someone else wants jest-worker@^27.2.0), but even then I wouldn't say we have more of a right to do that because we're Jest itself.
I understand that in the case of bugs it can be annoying, but I don't want such accidents to make us abandon a benefit of semver. It sets a bad precedent - as soon as a second major dependent of jest-worker or pretty-format or something does this everyone gets duplication.

[SimenB]

We could do it selectively on different packages. We've had bugs with people using a jest-runtime on a newer version of jest-runner and getting weird bugs.

But "commonly consumed" (whatever that means) packages like pretty-format, jest-diff and jest-worker could probably still use ranged? Not sure.

---

I'm more concerned about reducing bugs than reducing bloat in node_modules - the consumer can dedupe if they want

[jeysal]

the consumer can dedupe if they want

Well that's the thing, as soon as one other dependent specifies a different fixed version, they can't just dedupe anymore because the versions ranges don't overlap. yarn dedupe won't catch it anymore, and if you even notice, only overriding what the package.jsons say via resolutions or packageExtensions would actually dedupe. This would cancel out a big part of what semver usually achieves - allowing different versions of a package in a tree, but avoiding everyone in the tree getting a distinct one at the same time.

[alexandernanberg]

@jeysal I see your point, but the problems that come with that are not worth it imo. E.g. right now we're struggling hard with #10716 and pinning jest to a prior version won't work since it automatically installs the latest version.

I'd guess that there will be more of these situations in the future too, e.g that jest@x.0.0 has subtle bugs when used with @jest/core@x.1.0 etc

[github-actions]

This issue is stale because it has been open for 1 year with no activity. Remove stale label or comment or this will be closed in 14 days.