change(integrations/jest-plugin): Support passing transform options t…

[janmeier]

…o the plugin

Make the @sucrase/jest-plugin more configurable, by allowing to specify additional options that are passed to sucrase.transform. In our case, we needed to set the jsxRuntime to automatic.

I added @jest/transform as a dependency to get the correct type for transformOptions. It is quite a large package, so let me know if you would rather just hand-type it.

[alangpierce]

Thank you! Apologies for not having configuration in place already. One small request on changing it to make transforms configurable.

Were you able to test this (using yarn link or similar)?

[codecov]

Codecov Report

Merging #749 (9fe508b) into main (d8bf165) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #749   +/-   ##
=======================================
  Coverage   87.51%   87.51%           
=======================================
  Files          55       55           
  Lines        5887     5887           
  Branches     1394     1394           
=======================================
  Hits         5152     5152           
  Misses        466      466           
  Partials      269      269           

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[github-actions]

Benchmark results

Before this PR: 311.5 thousand lines per second
After this PR: 316.8 thousand lines per second

Measured change: 1.72% faster (0.45% faster to 3.21% faster)
Summary: Probably faster

[janmeier]

I added a peer dependency on jest 27, since transformerConfig is not available before that. It was introduced here jestjs/jest@b0bf802

[janmeier]

Were you able to test this (using yarn link or similar)?

Yep, lint succeed and this change also works in our jest setup at Lenus

[alangpierce]

I added a peer dependency on jest 27

Thanks! That does make this change semver-major, but that should be fine. I'll also add a Sucrase peer dependency, should have had those in place from the start, really.

[janmeier]

Thanks for accepting this PR, and reviewing it quickly!

With this PR + some changes to our graphql typegen to work around #748 our tests are now green when running with sucrase 🎉 (previously we were running ts-jest)

That means I can now run the tests locally without running out of memory, and they are about 25-50% faster as well 🕺

[alangpierce]

Glad to hear it's helpful!

I'm still planning to release this to npm pretty soon, but since it's semver-major I want to fit a few other small things in (setting disableESTransforms to true by default, adding the peer dependency on Sucrase, and hopefully fixing #741 which should be pretty easy but I want to make sure it doesn't also need a semver-major change). Should be released in the next day or two, though.

Also, if you're digging into making Jest tests faster, you might want to try out https://github.com/nicolo-ribaudo/jest-light-runner . Sucrase still uses Mocha for the test suite because every time I've tried to switch to Jest I've run into slowdowns (~250ms -> ~5s for all the tests), I think mainly because of the VM isolation overhead. jest-light-runner is basically a Jest mode that disables that, so I've been meaning to try it out for Sucrase, but haven't dug into it much yet. But the perf concerns might also just depend on what sorts of tests you're writing.

[alangpierce]

Just released a new version of the plugin as 3.0.0

[janmeier]

Just released a new version of the plugin as 3.0.0

🎉

[janmeier]

Glad to hear it's helpful!

Also, if you're digging into making Jest tests faster, you might want to try out https://github.com/nicolo-ribaudo/jest-light-runner . Sucrase still uses Mocha for the test suite because every time I've tried to switch to Jest I've run into slowdowns (~250ms -> ~5s for all the tests), I think mainly because of the VM isolation overhead. jest-light-runner is basically a Jest mode that disables that, so I've been meaning to try it out for Sucrase, but haven't dug into it much yet. But the perf concerns might also just depend on what sorts of tests you're writing.

I did test jest-light-runner some time ago, but was blocked by the fact we needed to upgrade jest. We were on v26 before implemnenting sucrase, because of some major performance issues when using jest v27 and above together with ts-jest and tsc.

Now that we are using sucrase, we can upgrade to the latest version of jest, and might test out jest-light-runner after that.

As I see it, we would have to use ts-node with the sucrase integration, since jest-light-runner expects everything to be ES modules. Or maybe we could still use @sucrase/jest-plugin, given the fixes to ESM made in v3?

[alangpierce]

As I see it, we would have to use ts-node with the sucrase integration, since jest-light-runner expects everything to be ES modules. Or maybe we could still use @sucrase/jest-plugin, given the fixes to ESM made in v3?

I think you're right: Jest normally has a custom implementation of module loading, and @sucrase/jest-plugin is a plugin for that system, but jest-light-runner disables the system altogether, so you instead configure on-the-fly compilation the usual Node way (probably ts-node, or maybe something like sucrase/esm-loader in the future).

The ESM improvements in @sucrase/jest-plugin are for when you're running Jest the normal way; it passes some flags down to the transformer plugin saying whether the transformed code should target ESM, and @sucrase/jest-plugin now respects those flags. I think that whole step is skipped when using jest-light-runner, though.