Fix: jest-worker exposing .default babel interop
#5811
Conversation
|
Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file. In order for us to review and merge your code, please sign up 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 the corporate CLA signed. If you have received this in error or have any questions, please contact us at [email protected]. Thanks! |
|
Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks! |
|
Most of the tests are failing because of That is why I removed the Can you guys give any guidance needs to be done here? |
|
Note that add-module-exports only works on files that have just a default export; files that also have named exports need to either retain the .default, or avoid |
|
@ljharb So I can undo the last commit and remove |
|
That’s the shorter-term way to get unblocked :-) |
|
@felippenardi want to wrap this up so we can get into Jest 23? |
|
We're not gonna provide an interop here. I know it's ugly in CJS, but I don't think going down this track is worth it in the long run. We wanna move to ESM for all modules in this repo |
|
As talked about in the issue, a different approach using an intermediary file to unwrap the |
|
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
The issue #5803 raised up by @ljharb:
import a from 'jest-worker'works fine because it's using babel on both ends.However,
const b = require('jest-worker')results ina !== b, and to get at the proper value, you need to do b.default.Test plan
I will appreciate some help to evaluate if this is a valid change and if it solves the problem.