Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to specify path to tsconfig.json? #202

Closed
emlai opened this issue Sep 7, 2023 · 5 comments
Closed

How to specify path to tsconfig.json? #202

emlai opened this issue Sep 7, 2023 · 5 comments

Comments

@emlai
Copy link

emlai commented Sep 7, 2023

jest-runner-tsd is finding the wrong tsconfig.json (the one in a package subdirectory), instead of the correct one we use for tests (tsconfig.test.json at the root of the repo).

How can I tell jest-runner-tsd to use this custom tsconfig file?

@mrazauskas
Copy link
Contributor

It is not possible to specify the path explicitly.

tsd-lite picks up the closes tsconfig.json for each test file. Consider this file structure:

├── __typetests__
│   └── SampleType.test.ts
│   └── tsconfig.json
├── package.json
├── tsconfig.json
└── tsconfig.typetest.json

Here the file __typetests__/tsconfig.json has the following content:

{
  "extends": "../tsconfig.typetest.json",
  "include": ["./**/*"]
}

This is more or less how type testing is set up in Jest repo, see: https://github.com/jestjs/jest/blob/main/packages/expect/__typetests__/


Other solutions are possible. If the above suggestion does not work for your file structure, please provide more details on your setup.


The thing is that it is rather clumsy to pass additional options to the runners. For instance, Jest would not allow a --tsconfigPath flag. In the other hand, your IDE picks up nearest tsconfig.json for each file and uses compiler options found there. Nice to keep IDE and type test output in sync.

@emlai
Copy link
Author

emlai commented Sep 9, 2023

We have the tests in the same folder as the component they're testing. So having a parent tsconfig.json for just the tests is not possible. Our file structure looks more or less like this:

├── component-a
│   └── component-a.ts
│   └── component-a.test.ts
│   └── component-a.test.types.ts
├── component-b
│   └── component-b.ts
│   └── component-b.test.ts
│   └── component-b.test.types.ts
├── package.json
├── tsconfig.json
└── tsconfig.test.json

The main tsconfig.json doesn't include test files, only the actual code that makes up the release bundle.

tsconfig.test.json on the other hand includes all test files, nothing else.

@mrazauskas
Copy link
Contributor

mrazauskas commented Sep 10, 2023

Thanks for the details. Does your tsconfig.json also include:

{
  "references": [{ "path": "./tsconfig.test.json" }]
}

So that IDE could pick up the right config for test files? Reference: https://vite.new/react-ts


Ideally tsd-lite should look at references and use tsconfig.test.json, but it does not. Current implementation is using only compilerOptions and ignores all other fields. A quick fix: hardcode the path to ./tsconfig.test.json by patching this line: https://github.com/mrazauskas/tsd-lite/blob/ed190910b7983c10691f5cce9c1a2fd01bdb3247/source/utils/resolveCompilerOptions.ts#L8


The solution to this problem is coming with brand new type testing tool which is mentioned in #32. It respects all fields of TSConfig and picks up configuration just like IDEs do. (I.e. the references field must be there.)

Currently I work on documentation. The plan is to publish the package in some 2-3 months. The sooner the better, of course (;

@emlai
Copy link
Author

emlai commented Sep 14, 2023

Thanks!

We don't currently pass tsconfig.test.json to references, only to ts-jest directly.

Anyway, I ended up auto-generating the typing tests for all components on the fly when running tests, and running the resulting temporary file in a folder with a tsconfig.json. So I'm unblocked for now :)

@mrazauskas
Copy link
Contributor

Just a quick note, the testing tool I was mentioning before is freshly published. For details, see: #32 (comment)

So I think we can close this for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants