-
-
Notifications
You must be signed in to change notification settings - Fork 6.6k
feat(jest-config): supports Jest config file with .mts
extension
#15796
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
base: main
Are you sure you want to change the base?
feat(jest-config): supports Jest config file with .mts
extension
#15796
Conversation
Signed-off-by: hainenber <[email protected]>
✅ Deploy Preview for jestjs ready!Built without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify project configuration. |
babel-jest
babel-plugin-jest-hoist
babel-preset-jest
create-jest
@jest/diff-sequences
expect
@jest/expect-utils
jest
jest-changed-files
jest-circus
jest-cli
jest-config
@jest/console
@jest/core
@jest/create-cache-key-function
jest-diff
jest-docblock
jest-each
@jest/environment
jest-environment-jsdom
@jest/environment-jsdom-abstract
jest-environment-node
@jest/expect
@jest/fake-timers
@jest/get-type
@jest/globals
jest-haste-map
jest-jasmine2
jest-leak-detector
jest-matcher-utils
jest-message-util
jest-mock
@jest/pattern
jest-phabricator
jest-regex-util
@jest/reporters
jest-resolve
jest-resolve-dependencies
jest-runner
jest-runtime
@jest/schemas
jest-snapshot
@jest/snapshot-utils
@jest/source-map
@jest/test-result
@jest/test-sequencer
@jest/transform
@jest/types
jest-util
jest-validate
jest-watcher
jest-worker
pretty-format
commit: |
Signed-off-by: hainenber <[email protected]>
Signed-off-by: hainenber <[email protected]>
@hainenber type stripping is also enabled by default in node 22 since version 22.18.0 (see https://nodejs.org/en/blog/release/v22.18.0) |
Hi can we get this to merge? Is it changing to |
configObject = await loadTSConfigFile(configPath); | ||
if (isMTS) { | ||
// TODO: remove this once dropping Node 20/22 support. | ||
const mtsExtSupportVersionRange = '^20.19.0 || >=22.12.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.
type stripping was officially added to node 22.7.0 behind a flag --experimental-transform-types
so it might work then, why v22.12 here?
Additionally, it could be that it fails when --no-experimental-strip-types
is specified and within a supported version.
could this be simplified to a warning if all loader steps fail, and it's a mts file?
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.
type stripping was officially added to node 22.7.0 behind a flag --experimental-transform-types so it might work then, why v22.12 here?
22.12 is the version that can import ESM module natively, by default. You're right that users can specify experimental flags to have .mts
config to be consumed but from my POV, we should guide the usage towards defaults in Node runtime instead.
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 agree that we should direct users towards node defaults, but I think that trying to have specific version checks may not be that effective.
There is existing logic on line 48 that already determines if typestripping support is enabled in the process. Instead, could this change extend that logic, but without the fallback retry of CJS import? This may require updating jest-util
to also check for .mts
file extensions so it then only tries importModule
on.
This approach is then more compatible with other runtimes, like Deno and Bun.
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'm today-year-old to realize that there are process.feature.require_module
and process.feature.typescript
to test out a JS runtime's capability of loading ESM module with require
and type stripping, accordingly.
I'll probably adjust this PR to reflect that. Thanks for the lead!
…ping in Node >=22.18.0 Signed-off-by: hainenber <[email protected]>
Signed-off-by: hainenber <[email protected]>
Seems like the CI is still failing on these. Might need to disable them on older Node versions. |
CI is failing on multiple node versions, so I don't think the version itself is the issue. Looks like a regression? (would love to land this 😀) |
…est.config.mts for `create-jest` Signed-off-by: hainenber <[email protected]>
Signed-off-by: hainenber <[email protected]>
Signed-off-by: hainenber <[email protected]>
Signed-off-by: hainenber <[email protected]>
…time agnostic Signed-off-by: hainenber <[email protected]>
Signed-off-by: hainenber <[email protected]>
Signed-off-by: hainenber <[email protected]>
PR adjusted to be JS runtime agnostic, thanks to @ashleybartlett's suggestion. Jest should understand Hopefully CI gods let me through. |
Signed-off-by: hainenber <[email protected]>
Signed-off-by: hainenber <[email protected]>
Signed-off-by: hainenber <[email protected]>
Summary
Resolves #15780
This PR will allow
.mts
config file to be passed to Jest, enabling folks to work with native type stripping in CommonJS projects. However, full.mts
support is only for Node 23.6 and above due to type stripping enabled by default. On Node version^20.19.0 || ^22.12.0
, untypedjest.config.mts
would still be accepted by Jest but adding type would emit error.Test plan