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鈥檒l 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
Closed

Ambient types not working in 26.4.2 #2061

guyellis opened this issue Oct 24, 2020 · 4 comments

Comments

@guyellis
Copy link

@guyellis 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 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 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鈥檛 compile .d.ts which will boost performance a bit.

  • more inline with the definition of 鈥渢ype declaration鈥

@guyellis
Copy link
Author

@guyellis guyellis commented Oct 24, 2020

@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.

ahnpnl added a commit to ahnpnl/ts-jest that referenced this issue Oct 24, 2020
@InExtremaRes
Copy link

@InExtremaRes InExtremaRes commented Oct 26, 2020

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.

@ahnpnl ahnpnl closed this in #2062 Oct 26, 2020
ahnpnl added a commit that referenced this issue Oct 26, 2020
)

Closes #2061
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

3 participants
You can鈥檛 perform that action at this time.