feat(jest-config):Support loading TS config files via docblock loader#15190
feat(jest-config):Support loading TS config files via docblock loader#15190SimenB merged 17 commits intojestjs:mainfrom k-rajat19:jest-config-ts
Conversation
✅ Deploy Preview for jestjs ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
|
Thanks for sending a PR!
I think we should change default behaviour in a separate PR, just to keep the scope per PR down a bit |
Should I update docs in a separate PR ? after current one and PR which changes default behaviour lands |
|
Updating the docs here with info about the docblock makes sense. Even though we might delete parts of the new docs when changing default behaviour 🙂 |
| }; | ||
|
|
||
| let registeredCompilerPromise: Promise<Service>; | ||
| let registeredCompilerPromise: Promise<TsLoader>; |
There was a problem hiding this comment.
I wonder if this needs to be a Map<TsLoaderModule, Promise<TsLoader>>? I'm thinking in cases where multi projects are used, and some project uses a different TS loader. That might already not work if the loaders get in the way of each other, tho.
Maybe a better thing would just be to save what module was loaded, and then throw an error if later another one is attempted to be used?
There was a problem hiding this comment.
I have added integration tests for different loaders in different projects and they seem to be working fine d2c3a8d
do we still need to save the loader and doesn't allow using a different one?
| export default config; | ||
| ``` | ||
|
|
||
| If you are using `ts-node`, you can set `JEST_CONFIG_TRANSPILE_ONLY` environment variable to `true` (case insensitive) to read configuration files without typechecking. |
There was a problem hiding this comment.
not for this PR, but maybe in a follow-up - should we drop this new env variable and use docblock config instead (like we support for test environment: https://jestjs.io/blog/2022/04/25/jest-28#inline-testenvironmentoptions)? Then people could also e.g. opt into using swc (https://typestrong.org/ts-node/docs/swc/)
There was a problem hiding this comment.
that would be better, will send PR for that
we might also need to add support for swc based loader at some point #12156
| const tsLoader = docblockPragmas['jest-config-loader'] || 'ts-node'; | ||
|
|
||
| if (Array.isArray(tsLoader)) { | ||
| throw new TypeError( |
There was a problem hiding this comment.
This is not working when passing multiple loaders like this
/**@jest-config-loader ts-node esbuild-register*/ it simply returns a string 'ts-node esbuild-register' instead of returning an array of strings ['ts-node','esbuild-register']
is this an expected behavior or a bug in jest-docblock?
There was a problem hiding this comment.
that's expected - for it to be an array you'd need to do
/**
* @jest-config-loader ts-node
* @jest-config-loader esbuild-register
*/|
This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Summary
Unblocks #13143
Unblocks #11989
Added support for loading Typescript configuration files by specifying a loader in a docblock comment in config file.
this is a continuation of work done in #13742
one can define a loader in a docblock comment like this:
if there is no loader defined it uses
ts-nodeby default for loading a config file.currently there is support for
esbuild-registerandts-node.Test plan
Added e2e tests