Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix line number preservation for Jest transform #608

Merged
merged 1 commit into from
Apr 11, 2021

Conversation

alangpierce
Copy link
Owner

This is a follow-up from #540 (review)

For the Jest transform, rather than actually moving the jest.mock invocations,
it's better to transform them in-place and wrap them in functions, then call
those functions from the top of the file. That guarantees that line numbers are
preserved before and after so that the source map can be correct.

I also added the jest transform to the website so that it's easier to manually
test. It may be possible to hook up the ts-jest version of the transform to the
TypeScript output on the website, but I left that off for now.

To test, I made a simple Jest project and mocked a function that returns a
number. Without the jest tranform, putting the mock call below the import
doesn't work, and with the jest transform it works. Before this change,
breakpoints further down in the file (e.g. in the test) didn't work because line
numbers were wrong. After this change, breakpoints work.

I also manually tested this line to ensure that the chaining transform doesn't
break other uses of the jest object:

console.log(jest.spyOn({foo() {}}, 'foo').getMockName());

This is a follow-up from #540 (review)

For the Jest transform, rather than actually moving the `jest.mock` invocations,
it's better to transform them in-place and wrap them in functions, then call
those functions from the top of the file. That guarantees that line numbers are
preserved before and after so that the source map can be correct.

I also added the jest transform to the website so that it's easier to manually
test. It may be possible to hook up the ts-jest version of the transform to the
TypeScript output on the website, but I left that off for now.

To test, I made a simple Jest project and mocked a function that returns a
number. Without the jest tranform, putting the mock call below the import
doesn't work, and with the jest transform it works. Before this change,
breakpoints further down in the file (e.g. in the test) didn't work because line
numbers were wrong. After this change, breakpoints work.

I also manually tested this line to ensure that the chaining transform doesn't
break other uses of the `jest` object:
```javascript
console.log(jest.spyOn({foo() {}}, 'foo').getMockName());
```
@codecov
Copy link

codecov bot commented Apr 11, 2021

Codecov Report

Merging #608 (5beb07e) into main (6277a20) will decrease coverage by 0.07%.
The diff coverage is 100.00%.

❗ Current head 5beb07e differs from pull request most recent head ea43de7. Consider uploading reports for the commit ea43de7 to get more accurate results
Impacted file tree graph

@@            Coverage Diff             @@
##             main     #608      +/-   ##
==========================================
- Coverage   82.11%   82.04%   -0.08%     
==========================================
  Files          56       56              
  Lines        5861     5620     -241     
  Branches     1320     1320              
==========================================
- Hits         4813     4611     -202     
+ Misses        763      725      -38     
+ Partials      285      284       -1     
Impacted Files Coverage Δ
src/transformers/JestHoistTransformer.ts 95.12% <100.00%> (+1.78%) ⬆️
src/transformers/RootTransformer.ts 92.61% <100.00%> (ø)
src/Options-gen-types.ts 75.00% <0.00%> (-25.00%) ⬇️
src/parser/index.ts 77.77% <0.00%> (-7.94%) ⬇️
src/computeSourceMap.ts 83.33% <0.00%> (-5.56%) ⬇️
src/util/getNonTypeIdentifiers.ts 94.44% <0.00%> (-5.56%) ⬇️
src/parser/plugins/types.ts 91.66% <0.00%> (-3.34%) ⬇️
src/parser/tokenizer/readWord.ts 82.35% <0.00%> (-3.02%) ⬇️
src/parser/traverser/util.ts 86.20% <0.00%> (-2.17%) ⬇️
src/parser/traverser/base.ts 95.45% <0.00%> (-1.69%) ⬇️
... and 21 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 6277a20...ea43de7. Read the comment docs.

@github-actions
Copy link

Benchmark results

Before this PR: 273 thousand lines per second
After this PR: 273 thousand lines per second

Measured change: 0% faster (0.29% slower to 0.88% faster)
Summary: Likely no significant difference

@alangpierce alangpierce merged commit 04cb7c4 into main Apr 11, 2021
@alangpierce alangpierce deleted the fix-jest-line-numbers branch April 11, 2021 22:45
alangpierce added a commit that referenced this pull request Apr 12, 2021
Fixes #609

The original implementation of the Jest transform (#540) needed to remove
regions of code, but ran into issues with the optional chaining and nullish
coalescing transforms, since those transforms would still emit function calls
around tokens even if they were removed. The implementation fixed those issues
by disabling the optional chaining and nullish coalescing code emit in
`removeToken` and `removeInitialToken`. Unfortunately, this broke other cases,
like a nullish coalescing call immediately followed by a type token. The nullish
coalescing implementation expected `appendTokenSuffix` to be called on the last
token even though it was a type token.

The changes to `TokenProcessor` actually became unnecessary as of #608 since we
no longer are deleting a region of code, so I reverted the two methods back to
their original implementation, which fixes the issue.
alangpierce added a commit that referenced this pull request Apr 12, 2021
Fixes #609

The original implementation of the Jest transform (#540) needed to remove
regions of code, but ran into issues with the optional chaining and nullish
coalescing transforms, since those transforms would still emit function calls
around tokens even if they were removed. The implementation fixed those issues
by disabling the optional chaining and nullish coalescing code emit in
`removeToken` and `removeInitialToken`. Unfortunately, this broke other cases,
like a nullish coalescing call immediately followed by a type token. The nullish
coalescing implementation expected `appendTokenSuffix` to be called on the last
token even though it was a type token.

The changes to `TokenProcessor` actually became unnecessary as of #608 since we
no longer are deleting a region of code, so I reverted the two methods back to
their original implementation, which fixes the issue.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant