Jest: Feature: specify fixed dependency versions in package.json

[mmcgahan]

Dependencies break, especially in minor version releases (see istanbul-lib-instrument), but that shouldn't silently break every Jest consumer that re-installs without shrinkwrap.

Because you can't force everyone to use a 'shrinkwrap'-esque npm package managment system, I am strongly in favor of using specific, explicit dependency versions for Jest.

[cpojer]

These things happen from time to time. If you'd like explicit dependencies I encourage you to use Yarn and yarn lockfiles.

The proper fix for issues such as this is for istanbul to also run Jest as part of their integration testing. Maybe file an issue with them to ask about this! :)

[mmcgahan]

These things happen from time to time unless versions are pinned. Adding a shrinkwrap/lockfile obviates the issue, but that requires adding a tool to do what could be done simply at the source - the dependency list is objectively over-general. Converting it to be specific would 'avoid a whole class of bugs' as immutable folks like to say :). There will also be cases where even Yarn users will add Jest as a dependency at _just the wrong time_ (e.g. in the 6 hours or so yesterday that istanbul-lib-instrument was broken) and it will not work through no direct fault of the tool, which is unnecessary frustration.

Probably best not to require upstream dependencies to run downstream tests - that's one thing that dependency declarations are supposed to make unnecessary (no two-way binding, etc) and would be impractical to maintain with sprawling numbers of downstream dependents.

Hope that doesn't come across as harsh, just wanted to detail my reasoning a little more.

[cpojer]

It's not harsh, I appreciate feedback but I think it is not Jest's job to manage dependencies. I am in favor of auditing all of Jest's dependencies and loosen and tighten version ranges where it makes sense and will welcome a PR that does so but I don't believe exact dependencies are a solution to the problem you were experiencing.

I understand a bad patch release of a transitive dependency can break your entire test suite and that is unfortunate. The reason we are unaffected of issues like this at Facebook is precisely because we are using yarn lockfiles and an offline mirror. Version updates are always explicit and run through our entire CI system to make sure they are safe. If you are scared of patch or minor version updates breaking your product, I suggest fixing it in a similar way.

[mattkime]

I appreciate feedback but I think it is not Jest's job to manage dependencies

While I agree that its a wider problem with the npm secoystem, its disappointing that this should be considered an acceptable way of dealing with the problem.

[cpojer]

I'm open to listen to actual workable solutions to this problem and especially pull requests that don't compromise how semver is supposed to work rather than expressing your disappointment.

[bcoe]

@cpojer @mmcgahan my two cents, what I do with nyc is use bundled-dependencies;

I shy away from this for libraries I write with fewer dependencies, but it has been my experience with nyc, which has about 1,000,000 moving parts (the babel ecosystem, the istanbul ecosystem, etc.) that it's very much worth being very explicit with version updates.

The added benefit to this approach with nyc, is that it significantly speeds up install times; hundreds of HTTP requests become 1 or 2.

---

Having put my two cents out there; I apologize for the regression, I take the release process around Istanbul very seriously and work hard to avoid these sorts of regressions -- Would having Jest itself in my regression testing suite have caught this issue?

[cpojer]

@bcoe thanks for the perspective, this is much appreciated. I think running yarn test inside of the Jest repo may have caught this; I guess it shouldn't be too hard to verify.

bundled-dependencies is interesting; I wasn't aware it is a thing. I still do want users to receive patch updates for most things, though.

One thing I was planning on doing is to figure out the biggest dependencies of Jest and how we can trim the fat a bit. Jest is growing and I would like to make sure we don't regress on install times and startup performance.

[bcoe]

serves me right for playing Fallout New Vegas for three hours last night; one argument I'll put out there, a 6 hour turn around is pretty darn good -- would have been 2 had it not been for super-mutants.

[bcoe]

@cpojer I like the citgm project too, and have been thinking of figuring out a way to get a similar suite up and running for babel-plugin-istanbul/nyc.

[cpojer]

Ah, I believe the node maintainers said that Jest isn't compatible with citgm because of the monorepo we are using. That seems like something we should figure out so that we don't repeat the node 7.3 + console.log fiasko (OT for this issue).

[mmcgahan]

@bcoe I need to look into bundled-dependencies as well - looks good. And I was definitely happy with the 6 hour turnaround time for the regression fix!

@cpojer depending on how precise you want to get about allowing patch updates, you could keep that available while disallowing minor version updates with ~x.y.z rather than ^x.y.z, but that's probably beside the point :)

[bcoe]

One thing I was planning on doing is to figure out the biggest dependencies of Jest and how we can trim the fat a bit.

an interesting idea might be taking a highbred approach; bundle some of the bigger riskier dependencies, e.g., babel-plugin-istanbul, istanbul-lib-instrument (these come along with a chunk of the babel ecosystem, so it would be nice for them to come down in a single HTTP request).

[athomann]

@cpojer would you be able to point me to how I can lock versions for of a dependencies dependency? I need to lock instanbul-lib-instrument to 1.7.0 in jest-cli. Currently anything higher or lower breaks collectCoverage.

[bcoe]

@athomann mind openin an issue on Istanbuljs with a reproduction of this issue? The fact that both higher and lower versions are causing you issues sounds odd; I wonder if it's some sort of cache issue.

If you provide a repo having issues I'm sure I can debug for you.

[athomann]

@bcoe Here's the open issue. I'll try and get a repo open to replicate. https://github.com/istanbuljs/istanbuljs/issues/73