[Bug]: `--coverage` regression in jest v28.1.2

[trevor-scheer]

The --coverage flag has become unusable for us on the Apollo Server project as of the most recent patch. Tests fail unexpectedly with an unhelpful error.

Version

28.1.2

Steps to reproduce

1. git clone [email protected]:apollographql/apollo-server.git && cd apollo-server && git checkout 19143b99100310fb54b62caab4f306adc12fe954 && npm i (clone / init repo, checkout known good state commit)
2. ALLOW_CONSOLE=true npm run test:ci (this runs jest with --coverage)
3. Note tests all passing
4. npm i -D [email protected] [email protected] (update from 28.1.1 to 28.1.2)
5. ALLOW_CONSOLE=true npm run test:ci
6. Note surprising test failures with incomprehensible errors like the following:

 FAIL  packages/server/src/__tests__/express/integration.test.ts
  ● Test suite failed to run

    No element indexed by 57

      at ArraySet_at [as at] (../../node_modules/source-map/lib/array-set.js:109:9)
      at BasicSourceMapConsumer.SourceMapConsumer_originalPositionFor [as originalPositionFor] (../../node_modules/source-map/lib/source-map-consumer.js:673:30)
          at Array.map (<anonymous>)
          at Function.getOwnPropertyDescriptors (<anonymous>)

Expected behavior

I expect the latest version of jest to work as it has on the previous patch when using the --coverage flag

Actual behavior

Jest fails tests unexpectedly with unhelpful errors

Additional context

Possibly related, though this only happened to us on the most recent patch: https://github.com/facebook/jest/issues/12925

The proposed workaround of installing babel dependencies to the project did not work for us.

Environment

System:
    OS: macOS 12.3.1
    CPU: (8) arm64 Apple M1
  Binaries:
    Node: 16.15.1 - ~/Desktop/ApolloRepos/apollo-server/.volta/tools/image/node/16.15.1/bin/node
    npm: 8.13.1 - ~/Desktop/ApolloRepos/apollo-server/.volta/tools/image/npm/8.13.1/bin/npm
  npmPackages:
    jest: ^28.1.2 => 28.1.2

[glasser]

I reproduced the issue.

@SimenB https://github.com/facebook/jest/pull/12954 is the thing most coverage-related in the diff

[github-actions[bot]]

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

[SimenB]

@trevor-scheer @glasser Seems to me https://github.com/apollographql/apollo-server/pull/6674 updated it without issue, was this solved by updating some other dependency?

[glasser]

@SimenB Our resolution was to stop running with --coverage: https://github.com/apollographql/apollo-server/commit/4225ba6347f7e57e672a2f965f38ac7a6df914ed

[SimenB]

Not on main https://github.com/apollographql/apollo-server/blob/3f218e7881ba415a8817f6a8f1dca95d5571d93b/package.json#L20

Unless I'm missing something 😅

[glasser]

@SimenB The commit I linked is on the version-4 branch which is where a bunch of our active development is happening. Guessing the issue is only occurring there.

[trevor-scheer]

@SimenB what @glasser is saying is correct. The reproduction steps I provided take you to a point on the version-4 branch where this happens. Since then, we've bypassed coverage for now in order to not block jest updates. If you wanted to confirm whether or not this issue has cleared up, you can checkout version-4 (npm run clean && npm i if necessary) and run npm run coverage, which is the script we've disabled for now. FWIW, I just confirmed the issue still exists.

[SimenB]

So main is passing with newest jest, but some other branch is failing? Sounds like it's not (solely) on jest at least. Not sure I'll be able to dig into this, but I'll try to find the time.

Note that the commit you link to only affects the opt-in v8 coverage, not the default babel based one. So unless you opt in in v8 coverage that's not the commit with the regression

[glasser]

Right now, version-4 is our active development branch (main is our stable branch).

[SimenB]

The issue is with @jridgewell/[email protected] and higher, see https://github.com/SimenB/apollo-server/commits/trace-mapping-update which is on top of the last good commit and only updates that module in the lockfile.

@jridgewell would you be able to take a look? The command I'm running locally is ALLOW_CONSOLE=yes npx jest packages/server/src/__tests__/express/integrationServerless.test.ts --config packages/server/jest.config.js --coverage --no-cache fwiw.

Reverting the last commit on the linked branch makes the command pass.

It's weird the stack trace points to source-map, something fishy is going on 😅

[SimenB]

Opened a PR to apollo-server based on the above: https://github.com/apollographql/apollo-server/pull/6799

[jridgewell]

Just seeing this, I'll take a look.

[jridgewell]

The bug is https://github.com/jridgewell/trace-mapping/commit/165983e26d98abf2157c91469c1670f60235d8b0. Combined with presortedDecodedMap used by @ampproject/remapping v2.1.2 to generate based on a {...map} clone of a TraceMap instance. This incorrectly detects the clone as a TraceMap, and returns the instance, which contains private data that's now incorrect for the new mappings.

Note that presortedDecodedMap is no longer used by remapping (I upgraded it to use @jridgewell/gen-mapping). I'll fix the bug in trace-mapping, but this can also be resolved by upgrading the @ampproject/remapping transitive dependency (through @babel/core).

[SimenB]

Great, that works as well! Updated the PR. Thanks @jridgewell 👍

[jridgewell]

Fixed in https://github.com/jridgewell/trace-mapping/releases/tag/v0.3.15

[SimenB]

https://github.com/facebook/jest/releases/tag/v29.0.0-alpha.6

[dzienisz]

can you prepare fix for this bug for jest 27 and 28?

[SimenB]

The bug isn't in jest - it's via babel/trace-mapping. All of which are in semver ranger

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.