-
-
Notifications
You must be signed in to change notification settings - Fork 6.5k
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
feat(jest): allow enabling Jest global types through "types": ["jest"]
in tsconfig.json
#12856
Conversation
thanks! |
@@ -0,0 +1,8 @@ | |||
{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
__tests__
and e2e
directories needs additional tsconfig.json
with "types": ["jest"]
. That’s a lot of new files. For now I keep them all the same hoping this would help to review the PR. In few test suites some type fixing here and there is needed. Not touching these now. I will come back with fix PRs case-by-case.
Also here I have to extend the root tsconfig.json
, because tsconfig.json
in the enclosing directory is excluding __tests__
. Seems like excludes can not be overridden.
@@ -38,7 +38,7 @@ const copyrightSnippet = ` | |||
|
|||
const typesNodeReferenceDirective = '/// <reference types="node" />'; | |||
|
|||
const excludedPackages = new Set(['@jest/globals']); | |||
const excludedPackages = new Set(['@jest/globals', 'jest']); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bundling removes declare
. In any case, that is just one .d.ts
.
@@ -5076,16 +5075,6 @@ __metadata: | |||
languageName: node | |||
linkType: hard | |||
|
|||
"@types/jest@npm:^27.4.0": |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And... This is gone! ;D
expect({apples: 6, bananas: 3}).toEqual({ | ||
apples: expect.toBeWithinRange(1, 10), | ||
bananas: expect.not.toBeWithinRange(11, 20), | ||
}); | ||
}); | ||
``` | ||
|
||
:::note | ||
|
||
In TypeScript, when using `@types/jest` for example, you can declare the new `toBeWithinRange` matcher in the imported module like this: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This page can have more TS examples, of course. I just wanted to remove this old pain.
@@ -13,3 +13,26 @@ export { | |||
} from '@jest/core'; | |||
|
|||
export {run} from 'jest-cli'; | |||
|
|||
declare global { | |||
export const beforeEach: typeof import('@jest/globals')['beforeEach']; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
export
is not needed, because global
namespace is always public. I added export
just as a hint for future reader that these are being exposed here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
exciting! We should try to add a bunch of the helpers onto the jest namespace as well
"extends": "../../../../tsconfig.json", | ||
"compilerOptions": { | ||
"composite": false, | ||
"esModuleInterop": true, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we need this? (applies to all)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some tests needs it. For example, commenting out "esModuleInterop": true
give type error here:
My idea was to use the same tsconfig.json
file for all packages to simplify review. But I can go through and enable it case by case. This option applies only for files inside __tests__
directories. Perhaps it is fine to keep it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A separate PR making it unneeded would be awesome, but shouldn't clutter up this pr
declare const describe: Global.TestFrameworkGlobals['describe']; | ||
declare const test: Global.TestFrameworkGlobals['test']; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why are these needed? shouldn't they just import from @jest/globals
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah.. I reworked these into imports, but seems like these create circular references somehow – https://github.com/facebook/jest/runs/7819204971
Edit: @jest/globals
depend on expect
which depends on test-utils
. Unfortunately that’s circular. In contrary @jest/types
depends only on @jest/schemas
. Fingers crossed we will not need test-utils
for schemas ;D
interface Matchers<R> { | ||
toPrettyPrintTo(expected: unknown, options?: OptionsReceived): R; | ||
} | ||
declare module 'expect' { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
woo!
@@ -1,22 +1,8 @@ | |||
{ | |||
"extends": "../tsconfig.json", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let’s extend
this one too? Why not?
Hm.. Just noticed that "noEmit": true
went missing. Shall I bring it back? And perhaps shall I use it for all __tests__
?
Just looked through the |
I'm thinking of stuff like |
Right! Actual I can search on GitHub and see which ones are used: Edit: very exciting to look around. Even |
There is also https://github.com/facebook/jest/blob/ae8cf9a78cb0cd2f54d3bacbc1c8837e540e21dc/packages/jest-util/src/__tests__/installCommonGlobals.test.ts#L11 btw. I'm getting an error, is the namespace thing not working?
|
Good catch. The issue is with this PR. All works with |
export const jest: typeof import('@jest/globals')['jest']; | ||
|
||
// eslint-disable-next-line @typescript-eslint/no-namespace | ||
namespace jest { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not happy about the duplication with declarations in @jest/globals
.
Another problem – it was not a good idea to put everything into index
file. Now import {Config} from 'jest'
is also augmenting global
and pulling in Jest’s globals. That’s not good. So "types": ["jest"]
should be reworked into something like "types": ["jest/globals"]
. This means that "exports"
needs additional entry.
In a way all is fine, but at the same time the implementation becomes more and more hairy. In contrary import {expect, test} from '@jest/globals'
is simple and declarative. Does not need all the hairy stuff I mentioned. The more I work on this PR, the more I am a fan of that straight forward import
;D
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think requiring types: ['jest/global-api']
or something very explicit is perfectly fine 👍
@mrazauskas just wondering what the progress of this ticket is? I believe @SimenB is hoping to get this in V29. What are the remaining items to look into, would you like me to see if I can carve out some time to help? |
Brief answer: I am uncertain if this is a good idea. Have to think about it more and to do some testing. Perhaps it is not worth to postpone the release? This PR is a feature anyways, so it could land any time later. |
Yeah, currently leaning towards not having it in 29 - doing |
Closing in favour of #13344 and DefinitelyTyped/DefinitelyTyped#62037 |
This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Closes #12415
Summary
Based on the idea from #12853 (comment) by @ahnpnl
It was suggested to employ declaration merging of
global
scope and allow enabling Jest global types throughtsconfig.json
:That’s really nice. After playing a bit, I figured out that it is possible to have
declare global
directly inindex.ts
of'jest'
package. Simply install'jest'
, add global types through totsconfig.json
:Javascript project? Install
'jest'
, have your JS typed. Not sure I get how this works. Hm.. Seems like in this case globals become available in all files. No control. Not sure if that is fine? In the other hand, installing'jest'
and'@types/jest'
in a JS project gives the same effect.Ah.. It is possible to opt-out through
tsconfig.json
. So the difference:'@types/jest'
is opt-in, but adding this feature would force some JS users to opt-out. Feels breaking. Or at least annoying for sensitive people ;DTodo
Test plan
Type test is added.