feat(jest): SWC support for jest #308
Conversation
| @@ -25,6 +25,10 @@ module.exports = function () { | |||
| name: 'TypeScript support', | |||
| value: 'typescript', | |||
| }, | |||
| { | |||
| name: 'SWC for TypeScript (experimental)', | |||
There was a problem hiding this comment.
I'd use "Use SWC instead of ts-jest to transpile TypeScript (experimental, at least 20x faster transpilation, see )"
It's way longer, but provides more context about what SWC project is and why it's useful
| // }, | ||
| // }, | ||
| transform: { | ||
| [`^(${quasarEsModulesPackageNames}).+\\.js$`]: 'babel-jest', |
There was a problem hiding this comment.
Can we skip using babel-jest altogether and use @swc/jest for Quasar dependencies too? That would be a big plus, as we currently have to transpile Quasar ESM prod build when running Jest tests and Babel is pretty slow in doing that
There was a problem hiding this comment.
I'm not familiar with all the quasar build output so not sure what to point to. All I can say at this moment is that after commenting out this line, there is no performance difference (although it does still work)
There was a problem hiding this comment.
Tested on another machine... SWC might be slightly faster here (10%?) but not significant. It's definitely not slower and seems to work so I'll remove the babel-jest on next commit
| @@ -68,6 +68,14 @@ module.exports = function (api) { | |||
| }typescript`, | |||
| ); | |||
|
|
|||
| if (api.prompts.options.includes('swc')) { | |||
| api.render(`./templates/swc`) | |||
There was a problem hiding this comment.
I guess this relies on the fact that ts-jest files are scaffolded first, so we're overwriting the scaffolded ones here
It's ok to rely on this kind of execution-order assumptions due to it being experimental, but I'd make it explicit with a comment
| @@ -284,6 +284,10 @@ This AE ships with project-level type-checking disabled by default since it incr | |||
|
|
|||
| Project-wide type-checking already takes place during development and into your IDE, so you won't usually need this during tests anyway. | |||
|
|
|||
| ##### SWC support | |||
|
|
|||
| Experimental support has been added for [swc/jest](https://swc.rs/docs/usage/jest), which is a drop-in Rust replacement for ts-jest and should make your TypeScript Jest tests run faster. To install it, choose the relevant option when prompted on installation, ensuring also to choose typescript. | |||
There was a problem hiding this comment.
Is the SWC option meant to only pop out when you select TS support?
I think we can do so by adding a new question and making the SWC one conditionally bound to the TS one
Is it possible to use SWC for both JS and TS with the same configuration?
There was a problem hiding this comment.
I wanted it to only popup for typescript but the prompts API doesn't seem to support such an optional question. So currently it does nothing if typescript isn't also selected.
There was a problem hiding this comment.
IIRC Quasar uses Inquirer to process these prompts
You should be able to define a "when" option to control when to show a question
If you aren't able to do so, I'll take a look when you set the PR as ready to review
|
Some testing on a couple of projects I run. To test performance, I am using On the smaller project on a fast machine
On a large project including component testing on a slow machine
On same project without any component testing on a slow machine
|
|
Hey there! |
Sorry for radio silence... what's happened is that my projects have switched to vite and vitest so this is left hanging. For anyone still on webpack framework wanting to use SWC, this change is still good. But I don't think it is worth the effort anymore to make this a real plug-in enhancement. Instead, might simply be better to leave documentation on how people could switch to SWC. |
|
Ok, no problem, I'll close the PR in that case |
What kind of change does this PR introduce? (check at least one)
Does this PR introduce a breaking change? (check one)
If yes, please describe the impact and migration path for existing applications:
The PR fulfills these requirements:
devbranch and not themasterbranchfix: #xxx[,#xxx], where "xxx" is the issue number)If adding a new feature, the PR's description includes:
Other information: