Consider using TypeScript APIs to find and read tsconfig.json

[mrazauskas]

Clear and concise description of the problem

Consider using TypeScript APIs to find and read tsconfig.json instead of the get-tsconfig package.

If I get it right, only typecheck needs tsconfig.json and it also requires typescript to be installed. Hence a dependency (even if it gets bundled) seems to be redundant.

It is hard to reason about the exact amount of code which is shipped after bundling in the get-tsconfig package. Seems like parsing logic of jsonc-parser is still there. That will be always more than these few lines: https://github.com/privatenumber/get-tsconfig/#how-can-i-use-typescript-to-parse-tsconfigjson

Suggested solution

The solution is documented in get-tsconfig repo:
https://github.com/privatenumber/get-tsconfig#how-can-i-use-typescript-to-parse-tsconfigjson

Alternative

No response

Additional context

The install size of the get-tsconfig package is . Sounds too much for a library which simply walks the file tree, reads JSON files and parses them.

It might be worth checking what else can be shaved off, because currently the install size of Vitest is significantly larger than Jest’s (related discussion in their repo: jestjs/jest#6266).

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

[sheremet-va]

get-tsconfig is used to create a temporary tsconfig file. parseJsonConfigFileContent returns an internal tsconfig representation that we can't use as a temporary tsconfig file.

By the way, I am open to use tstyche for type checking if it doesn't patch typescript internals.

[mrazauskas]

Ah.. Got it. I thought there should be some trick.

Thanks for your interest in trying out TSTyche. I was thinking a lot about integrations with JavaScript testing frameworks. Probably a separate issue would suite better to talk about this.

Can I ask quickly why do you think that patching is the wrong thing in this case?

User has no accesses to those patched TS packages. They are kept outside of repo and are only used for type testing. So only TypeScript itself could call those additional methods during the test run, but we can be 100% sure that it does not.

Also since patching is done on demand, it is possible to adjust it if TS codebase is changing. That is not possible with, for example, @tsd/typescript.

It also would be wrong to patch TS package installed by the user. But TSTyche does not do that. It does not require TypeScript to be installed in a repo.

[sheremet-va]

Can I ask quickly why do you think that patching is the wrong thing in this case?

From what I understand, patching requires a separate version of typescript to be installed. Vitest supports third-party TS wrappers like vue-tsc (and probably volar in the future) which makes patching not work for every use case.

[mrazauskas]

Interesting. On surface vue-tsc looks more like a build tool, but it might be that TSTyche has to have support for it. I will take a better look. Thanks for the idea!

It is right that patching requires a separate copy of typescript to be installed. But testing on specified versions of TypeScript is not possible without installing a package for each version. TSTyche's cache is global, hence it is reused between projects. The footprint is minimal. The strategy is somewhat similar to tools like nvm.

(Closing this issue. The initial question was already cleared out.)

[sheremet-va]

On surface vue-tsc looks more like a build tool

Actually, it doesn't even work without noEmit flag (or at least it didn't for some time). It's just a type checker for Vue projects that rely on Volar type checking. It does expose createProgram though, so it might be possible to hook into programmatic API 🤷🏻

It is right that patching requires a separate copy of typescript to be installed. But testing on specified versions of TypeScript is not possible without installing a package for each version. TSTyche's cache is global, hence it is reused between projects. The footprint is minimal. The strategy is somewhat similar to tools like nvm.

Interesting! I was wondering how it works 🤔

[mrazauskas]

createProgram() is slow (; I was using it before. createProgram() is great if the goal is to reason about the whole project (before emitting files or so). That is too much for type testing. In this case it is enough to reason about a single file. Hence TSTyche is using project service API programatically, which is more or less how editors provide type information via tsserver binary. (Must say that I was adapting the idea by Jake Bailey, see: typescript-eslint/typescript-eslint#6575)

By the way, I looked for projects using checker: 'vue-tsc' and figured out what is missing in TSTyche. It does not know about .vue files and fails if an import from .vue is found. Obviously I must make this work. Thanks for pointing out this problem.

[sheremet-va]

createProgram() is slow (; I was using it before. createProgram() is great if the goal is to reason about the whole project (before emitting files or so). That is too much for type testing. In this case it is enough to reason about a single file. Hence TSTyche is using project service API programatically, which is more or less how editors provide type information via tsserver binary. (Must say that I was adapting the idea by Jake Bailey, see: typescript-eslint/typescript-eslint#6575)

One of the goals with Vitest type checker is to replace tsc --noEmit command, and just run vitest --typecheck, so we can't really allow ourselves this luxury 😄