Jest: Support typescript format configuration file

[septs]

🚀 Feature Proposal

To be able to fully use TypeScript

Motivation

Make the .js file not appear in the project.

Example

This allows us to TypeScript ONLY.

Expected:

// File path: project/jest.config.ts
import { Configuration } from "jest";
import { defaults } from "jest-config";

const configure: Configuration = {
    preset: 'ts-jest',
    testEnvironment: 'jest-environment-jsdom-fourteen',
    globals: {
        'ts-jest': {
            isolatedModules: true,
        },
    },
    moduleFileExtensions: [...defaults.moduleFileExtensions, 'ts', 'tsx'],
}

export default configure

Pitch

Why does this feature belong in the Jest core platform?

Common feature proposals that do not typically make it to core:

• New matchers (see jest-extended)
• Changes to the default reporter (use custom reporters instead)
• Changes to node/jsdom test environments (use custom environments instead)

Reference

https://github.com/kulshekhar/ts-jest/issues/1415

[nvdnkpr]

Any reactions on this question ?

[MarcoScabbiolo]

I don't think this is worth it. Jest runs on Node and requires your config file using Node. For jest to support .ts config files it would need to transpile it and then run it, which you could do yourself very easily if you really need a Typescript configuration file.

Although jest handles transpilation very well thanks to babel-jest and Babel, it does so in the tests once jest if fully configured, loaded and up and running. Having to do this transpilation just to read the configuration file can be both difficult or cumbersome to implement and result in a slower setup.

I just haven't seen and can't think of a project that needs a jest configuration so complex that type checking for it becomes necessary. Jest already supports complex scenarios like monorepos very well with relatively simple configurations. The fact that you use and like typescript doesn't mean you have to use it in every single line of code and every file must be a .ts file.

[G-Rath]

We've got an issue tracking implementing transforming just about everything possible, but config isn't on there.

I think supporting a .ts config would be a good thing, as it'll allow for editors to provide far better feedback on if a configuration is valid or not, along with providing a continued consistent experience both against jest & other projects such as danger & webpack

This should be relatively easily implemented using the standard ts-node method that the majority of other projects use. The interesting part would be the actual type to recommend, which is being tracked here.

[jeysal]

Well the key difference between this and everything else on that list is that the config specifies how to transform everything else. To transform the config itself, we'd have to assume defaults.

[G-Rath]

For general transforming totally, but for just TypeScript the configuration is handled by ts-node, which has been made even easier now that the ability to configure it via the tsconfig.json has been merged.

i.e you can do:

{
  "compilerOptions": {
    "target": "ES2019",
    "module": "commonjs",
    "moduleResolution": "node",
    "lib": ["ES2020"],
    "rootDir": "./",
    "baseUrl": "./",
    "paths": {
      "@src/*": ["./src/*"],
      "@test/*": ["./test/*"]
    },
    "plugins": [{ "transform": "ts-transform-paths" }]
  },
  "exclude": ["coverage", "node_modules", "lib"],
  "tsNode": {
    "compiler": "ttypescript"
  }
}

There are definitely a few minor caveats and differences, but I think overall it's do-able with minimal effort.

[brieb]

We had a use case for moving the Jest config to TS as well.

We ended up writing a (somewhat hacky) script that uses this feature of jest cli.

--config ...
This can also be a JSON-encoded value which Jest will use as configuration.
https://jestjs.io/docs/en/cli#--configpath

If a TS config is passed in, we JSON.stringify it then pass it to jest.

Using this approach along with babel-register, allows us to write our jest config along with any custom jest runners in TS.

The approach looks something like this: https://gist.github.com/brieb/e055e8df36769862bf2907893b3f9a81
Posting this here in case it's useful for others too.

Has there been further thought for supporting TS configs?
Now that Jest supports TS tests out of the box, we were hoping that might be a possibility too.
As it looks like Jest already supports some different types of config file extensions already.

Jest's configuration can be defined in the package.json file of your project, or through a jest.config.js file or through the --config option.
https://jestjs.io/docs/en/configuration

[dl748]

@MarcoScabbiolo I think its worth it, if you you don't consider the narrow scope of TypeScript. Webpack offers the user a choice of language for configuration files.

https://webpack.js.org/configuration/configuration-languages/

through the

https://www.npmjs.com/package/interpret

Doing it this way, allows developers to choose the language they want, to represent the configuration file. As long as they have the proper interpreter registered, the system should automagically just run it.

[glennreyes]

I don't think this is worth it. Jest runs on Node and requires your config file using Node. For jest to support .ts config files it would need to transpile it and then run it, which you could do yourself very easily if you really need a Typescript configuration file.

Although jest handles transpilation very well thanks to babel-jest and Babel, it does so in the tests once jest if fully configured, loaded and up and running. Having to do this transpilation just to read the configuration file can be both difficult or cumbersome to implement and result in a slower setup.

I just haven't seen and can't think of a project that needs a jest configuration so complex that type checking for it becomes necessary. Jest already supports complex scenarios like monorepos very well with relatively simple configurations. The fact that you use and like typescript doesn't mean you have to use it in every single line of code and every file must be a .ts file.

I disagree. To me it's a huge win if I can get a fully typed configuration without ever having to look up the documentation for every single option anymore. I'd rather have auto suggestions popping up in my editor than an X ms faster initial execution.

[Gamote]

@septs, @nvdnkpr, @G-Rath, @brieb, @dl748, @glennreyes

Hi guys, I hope this is what you were looking for: #10564 ✌️