Open SimenB opened 3 years ago
I think it’s wise to pin this issue so it stands out to everyone :)
sure 🙂
I think we can already drop the support node 10 for jest@27
, there is no need to wait for jest@28
as it will reach EOL. :+1:
D-Day for Node 10 is here xD
Jest 27 will support Node 10 so people who are stuck on older versions (of which there are many) can use it
@SimenB you listed globalSetup
as one of thing to migrate to ESM but I don't see setupFiles
. Is it an omission or it will be taken care with globalSetup
?
setupFiles
are part of the test run, so that already works 🙂
Maybe that's one of the modules I am using but I cannot use ESM in my setupFiles
with the current version 27.0.0-next.9
Could you open up a new issue with a reproduction?
I want to do reporters
and resolver
, then release v27. Anyone up for sending PRs for those?
reporters
: https://github.com/facebook/jest/blob/a4358d619131498287e25a2c2f604f813481ddeb/packages/jest-core/src/TestScheduler.ts#L403resolver
: A bit more involved as we'll need to load the resolver ahead of time instead of on demand. I.e. passing a resolverModule
option in addition to resolver
? The place it's require
d today needs to stay synchronous. https://github.com/facebook/jest/blob/master/packages/jest-resolve/src/index.ts#L108Maybe that's one of the modules I am using but I cannot use ESM in my
setupFiles
with the current version27.0.0-next.9
Hi @gilles-yvetot
If you want to fix the setupFiles
thing, you can compare your approach to what I'm doing in firebase-jest-testing. It uses both Jest 27.0.0-next.9 and ESM globalSetup
.
Decided to skip resolver
for now, as I think having to make it async will probably be more natural together with adding async resolution in #9505.
Opened up #11427 for reporters
Should moduleNameMapper
be part of this meta-task?
Hmm, maybe. I'd have assumed that worked as it should seeing as it should just remap the identifier and the rest should work as "normal". Is that not the case?
I tested it, and it does work 😆
Hi @SimenB, I just try to help doing these parts:
After I dived into it, I found there're some problems that I can't solve by myself.
dependencyExtractor
is used in the constructor:
So the only chance I could find is to make the whole HasteMap factory async like this:
await HasteMap.create(...);
Is this a right approach?
prettierPath
is required using a helper called requireOutside
:
This requireOutside
function will be transformed by babel-plugin-jest-require-outside-vm
:
I currently don't have enough knowledge about how to handle this with ESModules.
Those two are relying on the localRequire
function:
So, should we pass runtime.unstable_importModule.bind(runtime)
as localImport
to solve this problem?
Wonderful, thanks!
dependencyExtractor
Yeah, that seems correct. Makes it a breaking change though, so need to wait for Jest 28.
prettierPath
Good point, we might have to leave that alone. This is for a specific module (prettier
) though, so not as likely that people plug in their own thing which is ESM. If (when) prettier
migrates to ESM only, we must change, but up until that leaving it as require
seems sensible.
snapshotResolver
&snapshotSerializers
Yeah, passing in unstable_importModule
makes sense. Should probably also pass in https://github.com/facebook/jest/blob/3d04f33daa3b9ec21838c9177ab7acab8c983155/packages/jest-runtime/src/index.ts#L421
Passing localRequire
, unstable_importModule
and unstable_shouldLoadAsEsm
through multiple layers looks a little bit tricky and breaks function signature unavoidably.
How about replacing localRequire
with a localRequireOrImportModule
function?
That should work as well 👍
@SimenB is there any work left to do? I am very glad to push these things forward.
Great! The ones not crossed out in the OP are still missing. Not sure how feasible they are
@SimenB is this waiting for nodejs team to provide support?
HI @SimenB i'm currently facing badly issue using jest ES6 to mock axios in nodejs jest doesn't mock axios like when using ESM like it was when using require to import module Please take a look here https://github.com/axios/axios/issues/5676#issue-1682834041
Is it possible to make expect
ESM compatible?
ESM compatibility is worthwhile since it can be installed as a separate module/dependency.
Good point, we might have to leave that alone. This is for a specific module (
prettier
) though, so not as likely that people plug in their own thing which is ESM. If (when)prettier
migrates to ESM only, we must change, but up until that leaving it asrequire
seems sensible.
Prettier seems to have moved on to ESM: https://prettier.io/blog/2023/07/05/3.0.0.html.
🎻
Once Node 10 is EOL at the end of April, lots of libraries and modules will probably be written in native ESM rather than CJS. While we've mostly been focusing on getting tests running in ESM, we're sorta limited/slowed down by the fact the
vm
APIs are experimental and flagged on Node's side. That is not the case for "normal" ESM.We already support user configuration written in ESM.
With that in mind, all modules in Jest that are "pluggable" should be able to load ESM.
dependencyExtractor
(#12008)globalSetup
(#11267)globalTeardown
(#11267)preset
(#11200)prettierPath
reporters
(#11427)resolver
runner
(#11232)snapshotResolver
snapshotSerializers
testEnvironment
(#11033)testResultsProcessor
(#12006)testRunner
(#11232)testSequencer
(#11207)transformers
(#11163)watchPlugins
(#11315)Any and all help here would be greatly appreciated!
In general, it means attempting to
require
, and if that fails with an ESM error, useimport()
and verify it's thedefault
export. Paired with an integration test that has the module in question written in ESM and verifying it works.Example: https://github.com/facebook/jest/blob/ab014c140af2e10ae7c5790c2406009790787cdb/packages/jest-transform/src/ScriptTransformer.ts#L177-L196
Whenever we drop Node 10 (probably for Jest 28) we can do just the
import
call as that can load both ESM and CJS, but that'll be a simple refactor as it's just removing the initialrequire
andtry-catch
. So I still think it's worth it to add support now as the code difference is quite small and the later refactor is minimal