swc: @swc/jest does not produce the correct source map for TypeScript

Describe the bug

When switching from babel-jest to @swc/jest, the sourcemap is not correct, producing incorrect code coverage.

When using babel-jest:

----------------------------|---------|----------|---------|---------|-------------------
File                        | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s 
----------------------------|---------|----------|---------|---------|-------------------
All files                   |   99.49 |    95.77 |     100 |   99.81 |                   
 ts                         |   99.59 |    99.47 |     100 |     100 |                   
  constants.ts              |     100 |      100 |     100 |     100 |                   
  hasTersifyFn.ts           |     100 |      100 |     100 |     100 |                   
  AcornTypes.ts             |       0 |        0 |       0 |       0 |
  index.ts                  |       0 |        0 |       0 |       0 |
  ...BinaryOperatorOrder.ts |     100 |      100 |     100 |     100 |
  tersifyAcorn.ts           |   99.37 |     93.1 |     100 |   99.66 | 598
----------------------------|---------|----------|---------|---------|-------------------

When using @swc/jest:

----------------------------|---------|----------|---------|---------|-------------------
File                        | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s 
----------------------------|---------|----------|---------|---------|-------------------
  tersible.ts               |     100 |      100 |     100 |     100 |
  tersify.ts                |     100 |    98.97 |     100 |     100 | 14
  ...nction.browser.spec.ts |       0 |        0 |       0 |       0 | 2-1511   <-- this one is fine. The test is disabled due to swc codegen formatting issue.
  ...ifyFunction.browser.ts |       0 |        0 |       0 |       0 | 2-16     <-- this one is fine.
  tersifyFunction.ts        |     100 |      100 |     100 |     100 |
  ...ifyFunctionByString.ts |    4.49 |        0 |       0 |    5.12 | 9-145    <-- this one is fine.
  trim.ts                   |     100 |      100 |     100 |     100 |
  types.ts                  |     100 |      100 |     100 |     100 |
  typesInternal.ts          |       0 |      100 |     100 |       0 | 2
 ts/tersifyAcorn            |   95.46 |    87.01 |     100 |   96.02 |
  AcornTypes.ts             |       0 |      100 |     100 |       0 | 2
  index.ts                  |   42.85 |    33.33 |     100 |   47.36 | 20-36
  ...BinaryOperatorOrder.ts |     100 |      100 |     100 |     100 |
  tersifyAcorn.ts           |   98.76 |    91.95 |     100 |   99.01 | 391-392,502       
----------------------------|---------|----------|---------|---------|-------------------

repro: https://github.com/unional/tersify/tree/swc-vs-babel

run yarn coverage -c jest.config.swc.js

When there are test failure, the call stack is wrong due to the same reason, so the incorrect failure line is highlighted.

Input code

Adding


{
  transform: {
    '^.+\\.(t|j)sx?$': ['@swc/jest'],
  }
}

to `jest.config.js`

Config

{
  "jsc": {
    "parser": {
      "syntax": "typescript",
      "tsx": false,
      "decorators": false,
      "dynamicImport": false
    },
    "target": "es2020"
  }
}

Playground link

No response

Expected behavior

The source map and code coverage should be correct.

Actual behavior

No response

Version

1.2.124

Additional context

No response

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Comments: 25 (11 by maintainers)

Most upvoted comments

image

I was thinking something wrong. It was not a problem that can be fixed by adding spans. We should remove them. 🤣 This is what babel does.

Okay, I checked that ESM version is good while common js version is bad.