-
-
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
Add esbuild resolver for jest.config.ts
#12041
Add esbuild resolver for jest.config.ts
#12041
Conversation
Hi @jensmeindertsma! Thank you for your pull request and welcome to our community. Action RequiredIn order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you. ProcessIn order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA. Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with If you have received this in error or have any questions, please contact us at cla@fb.com. Thanks! |
Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks! |
1 similar comment
Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks! |
Just need to fix some dependency conflicts, will get to that within a few hours. |
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 found this annoying, Jest doesn't check the types of my tests, so why should it for my config? Let me check my own types please :)
Because it's not Jest doing that, it's TypeScript, and it's easier for the user to disable this behaviour than it is to try and re-enable it after we've hard-coded disabling it. This also matches the general default for the rest of the TS ecosystem (e.g. ts-jest
& typescript
both check types by default)
supports importing other files in your config file ( not sure whether ts-node supported this ).
Yes it does.
I think there's value in supporting options like this, especially when there's not a whole lot of extra code required + esbuild
is pretty popular these days :)
|
||
await esbuild({ | ||
// By bundling we add support for importing stuff in the config file. | ||
bundle: 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.
I don't think it's a huge risk, but fwiw arguably there's a security angle here where if someone were to import a dependency which itself imported a lot of files, the resulting file on disk would be huge.
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.
Yeah, I don't think this would be a problem. I added this option only because I was told there will be users who import other files in their config file, then this is a necessity.
Codecov Report
@@ Coverage Diff @@
## main #12041 +/- ##
==========================================
- Coverage 68.77% 68.75% -0.03%
==========================================
Files 324 324
Lines 16670 16675 +5
Branches 4814 4815 +1
==========================================
Hits 11465 11465
- Misses 5172 5177 +5
Partials 33 33
Continue to review full report at Codecov.
|
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.
What use cases are there for dynamic importing in config files?
The immediate one that springs to mind is importing an ESM based package, since that requires a promise. Outside of that, I imagine there are probably folks (and companies) out there that are doing more logic than we'd initially expect in their configs 😅
I don't think this is necessarily a blocker to not have, but is something that'd be nice in the long-run, especially since it's already supported by ts-node
.
try { | ||
require('esbuild'); | ||
} catch (error: any) { | ||
if (error.code === 'MODULE_NOT_FOUND') { | ||
throw new Error( | ||
`Jest: 'ts-node' or 'esbuild' is required for the TypeScript configuration files. Make sure it is installed\nError: ${e.message}`, | ||
); | ||
} | ||
|
||
throw error; | ||
} | ||
|
||
registerer = require('esbuild-register').register(); |
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.
The requiring of esbuild-register
should be done in this try/catch, and the error message should be updated to say esbuild-register
instead of esbuild
.
I don't think we need to be checking that esbuild
itself is installed as it's a peer dependency of esbuild-register
so that package should be handling checking if it's available (+ package managers will say that its needed due to being listed as a peer dependency)
if (tsNode) { | ||
registerer.enabled(false); | ||
} |
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.
The registerer needs to be disabled before this function returns because otherwise it will continue to run on unrelated files which will mess with Jest's transformation abilities & expectations, and cause a bunch of weird bugs (e.g. Jest can end up getting js versions of ts files, which'll not get mapped back to their sources when showing failure messages & stack traces).
Sadly it looks like esbuild-register
doesn't support being enabled and disabled, so that will a block - however it shouldn't be hard to implement and if it's done with the same API as ts-node
we should be able to leave these enabled
calls as is.
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.
Should I open an issue on esbuild-register
?
packages/jest-config/package.json
Outdated
@@ -14,9 +14,13 @@ | |||
"./package.json": "./package.json" | |||
}, | |||
"peerDependencies": { | |||
"esbuild": ">=0.13.12", |
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 should be replaced with esbuild-register
, since that is what Jest actually needs to do the work.
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.
You're right, however esbuild-register
specifies esbuild
as a peerDependency so we'll still need the user to install esbuild
|
Okay, this is now ready! To use this, the user must install |
What's the status on this? |
@G-Rath Any estimate on a timeline? |
@Zexuz I'm just a contributor to Jest, not a member so I can't merge this (I can't even approve it because I don't have any access to the repo, due to GitHub's new rules) - as it stands the PR looks almost good to go, it just needs to be rebased (I think because the upstream fork has been deleted, GH isn't saying it needs rebasing but it does). @SimenB is the one who manages Jest so is the person whose approval you really need to get this merged. @jensmeindertsma are you still interested in landing this? I might be able to pick it up if @SimenB is happy with the approach, but I don't currently use (a possible alternative that I would be interested in discussing is making some |
My current thinking is #13143 (comment) - we shouldn't change our default, but we should allow people to define what they want to use as a docblock comment. Happy to take a PR which does that 👍 |
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. |
Summary
I was using Jest with a
jest.config.ts
config file written in TypeScript and I found it annoying that I had to make changes to mytsconfig.json
file in order for it to work. This pull request adds a fallback option tojest-config
where ifts-node
isn't installed it will try to useesbuild
instead.esbuild
is faster, doesn't check types ( I found this annoying, Jest doesn't check the types of my tests, so why should it for my config? Let me check my own types please :) ), and supports importing other files in your config file ( not sure whetherts-node
supported this ).Test plan
I made the change, then ran these commands to verify things work:
The tests in my demo repository are passing, which means this change works! It successfully loaded the TS config file without
ts-node
installed.Oh yeah, this closes #11989 and #11453, although the latter one probably requires some docs updates.