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

Ambient types not working in 26.4.2 #2061

Closed
guyellis opened this issue Oct 24, 2020 · 4 comments · Fixed by #2062
Closed

Ambient types not working in 26.4.2 #2061

guyellis opened this issue Oct 24, 2020 · 4 comments · Fixed by #2062

Comments

@guyellis
Copy link

guyellis commented Oct 24, 2020

💥 Regression Report

Ambient types are not being picked up by ts-jest in 26.4.2

(Edit per comments below: If the ambient types are declared in a .ts file instead of a .d.ts file.)

Last working version

Worked up to version: 26.4.1

Stopped working in version: 26.4.2

To Reproduce

This PR has the errors: guyellis/plant#4180

Expected behavior

Ambient types are picked up.

Link to repo (highly encouraged)

This PR has the errors: guyellis/plant#4180

envinfo

System:
    OS: Ubuntu 20.04

Npm packages:
    jest: 26.6.1
    ts-jest: 26.4.2
    typescript: 4.0.3
    babel(optional): n/a
@ahnpnl
Copy link
Collaborator

ahnpnl commented Oct 24, 2020

A bit more information about this one. In #2055 I made a change that initially, TypeScript compiler will fetch only .d.ts (type declaration) to boot startup speed.

In your scenario, your ambient types are declared in .ts instead, so ts-jest failed to compile due to the fact that those ts are missing from compiler memory.

I safely assumed everyone uses .d.ts when making that change but seem like not always the case.

@ahnpnl
Copy link
Collaborator

ahnpnl commented Oct 24, 2020

The fix will still be in. IMO I would suggest you to start changing to use .d.ts. It will bring 2 advantages:

  • ts-jest won’t compile .d.ts which will boost performance a bit.

  • more inline with the definition of “type declaration”

@guyellis
Copy link
Author

@ahnpnl I agree that having those ambient types in .ts and not .d.ts files is a mistake. My plan is to keep those types in .ts files but make them non-ambient but I haven't got to that refactor yet. Thanks for taking care of this.

@InExtremaRes
Copy link

FWIW (and if I understand this thread correctly) I'm using ambient declarations to implement some Jest custom matchers. They're in a .ts file (not .d.ts) to keep the types and the implementation close to each other. The file is loaded with setupFilesAfterEnv at runtime.

In other project I have augmentations to the "global" module with types and runtime code so they are also in .ts files. When I'm just declaring global types I usually use .d.ts but it doesn't always plays well with other tools or if skipLibCheck is set to true. So IMHO is not always better to use .d.ts files and they probably shouldn't be skipped without a way to disable such behavior.

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

Successfully merging a pull request may close this issue.

3 participants