Support jest.config.ts

[bulldog98]

If you changed your global jest.config.js to jest.config.ts, the library generators, e.g. @nrwl/angular:lib will generate a jest.config.js file in root and ignore the jest.config.ts

Current Behavior

A new /jest.config.js is generated and the lib/jest.config.js references that root jest.config.js

Expected Behavior

I'd expect the no new jest.config.js in the root, and the jest.config.js file in the library to reference the jest.config.ts, maybe even generate a jest.config.ts instead.

Steps to Reproduce

1. Use jest in your nx workspace
2. Rename /jest.config.js to /jest.config.ts
3. Adjust the config to typescript
4. Change all references to jest.config.js to jest.config.ts
5. Add a new lib with a generator, e.g. @nrwl/angular:lib using jest as testing runner

[HansFalkenberg-Visma]

seconded

[barbados-clemens]

Thanks for opening the issue. I'm not sure I see the benefit of supporting a ts file for the jest config. what utility is gained from using typescript here? it's just a configuration file.

[HansFalkenberg-Visma]

To sum it up:

1. jest supports both, why wouldn't nx also?
2. As an executable file, we want to perform checks on it with eslint.
3. As a hand edited file, we want to ensure formatting with prettier.

To detail 1):
TypeScript allows you to do const config: Config.InitialOptions = {}, which will give you auto-completion and compile time checking of your configuration.

To detail it 2) and 3):
Your assertion that it just a config file is wrong. It is actually an executable file. .yaml (or even .json) would be config files. .js (and .ts) are executable files, and a such not just configuration files, even if they are used to hold configuration.

Put this inside jest.config.js: console.log('NOT A CONFIG FILE');
Expected result if it was just a config file: Parsing exception, or nothing happens.
Actual result: NOT A CONFIG FILE is written to the console.

Setting up eslint and prettier and the IDE(s) to work smoothly with TypeScript can be enough of a chore. We don't want to have to configure it for JavaScript too.

[HansFalkenberg-Visma]

I certainly understand if this isn't a high priority, but I wouldn't want it to not be prioritized at all.

[barbados-clemens]

Thanks for clarifying @HansFalkenberg-Visma!

Right now it's not the top of my list to support. As mentioned it works today and you can rename the file and adjust as needed for a workaround. But it's a good candidate for a community contribution as it's should adding an option for using TS and updating the generated path in the package/workspace json for the jest executor.

Happy to help guide anyone who wants to take this on. Otherwise I'll get to it after a couple other issues that'll be in front of this one.

[ognen]

I'm not sure that just renaming the jest config to .ts is the proper way to solve this issue. Nx claims it can be used w/o TypeScript (and we do).

It's one think to have a global typescript config file that nx maintains and no-one in the teams touches -- it is a wrinkle but okey.

It's completely different to force TS with jest config files that are used and maintained by the teams. Might be a small thing for someone using TS but it brings a new world to people not using it -- new language, new toolset, new gotchas etc...

(just landed with this issue after a migration just renamed all jest config files to .ts even though the workspace uses the --js preset).

[jbjhjm]

I agree with @ognen . Using typescript is no issue for me, but forcing it for everyone by migration doesn't make sense to me.
It changed/replaced hundreds of configuration files, leaving our repo with almost all tests failing with cryptic error message. Not sure if it was because of jest 28 or the change to ts files. But that's impossible to distinguish when it happens all at once.
Rolled back to jest 27 + js config files and all is working fine again.

[github-actions]

This issue has been closed for more than 30 days. If this issue is still occuring, please open a new issue with more recent context.