Ts-jest: [Improvement] Let typescript load the config file, instead of tsconfig package

[DorianGrey]

Hi there,

I've just switched some of my playground projects to use ts-jest instead of my own typescript preprocessor.
While I really appreciate to have less code to maintain, I've recognized that ts-jest uses a quite complex way to load the configuration file built upon the tsconfig package.

And I'm wondering why. Typescript itself offers a readConfigFile function:

import * as tsc from "typescript";

const result = tsc.readConfigFile("tsconfig.json", tsc.sys.readFile);

In this example, result.config would contain the config in case everything worked fine, or some diagnostics in result.error in case it failed to read it.
It would be especially useful in terms of the extends property, which is handled automatically (and its handling in the TS source looks by far more complicated than the one from ts-jest).

Any thoughts?

[kulshekhar]

I can't recall all details of why it is read in the way it is, currently, but this is definitely worth a look

[GeeWee]

using tsc.readconfigfile for me only results in a parsing of the actual JSON - I'm unsure how to translate that to an actual compilerOptions object.

Would love a PR.

[DorianGrey]

The result of tsc.readConfigFile is an object with either a config field containing the parsed file content, or an error field indicating that something went horribly wrong.
In case of the config object, that one would contain the compilerOptions field as defined in the config file, possible merged from multiple ones in case the reader had to follow the extends directive at least one time.

I'll see if I can get some spare time tomorrow, and I'll take care of a PR.

[GeeWee]

Strange. In my attempts I simply got an object with an "extends" key.
That'd be awesome

[DorianGrey]

Hm... yes, things seem to be a bit more complicated, though I'm a bit surprised - I recently used the same for a PR in another project, and things worked fine. I'll dig a little bit deeper into this...

€dit: Ok, after taking a closer look, I can confirm that tsc.readConfigFile does not follow the extends directive. It's a bit surprising to me, since I've seen that working without a problem in several projects, not only mine - otherwise, I wouldn't have suggest to go this way.

However, after checking out how TypeScript's cli is picking up the config, it seems to involve the usage of tsc.parseJsonConfigFileContent as well. Due to the source, this one recursively follows the extends entry, picking up the referenced files and merging the options as intended. I'll see if I can get that working.