Migrate jest-runner to typescript#7968
Conversation
|
|
||
| environment.global.process.exit = function exit(...args) { | ||
| (environment.global as NodeJS.Global).process.exit = function exit( | ||
| ...args: Array<any> |
|
Regarding your |
|
Just pushed some more changes. Let me know what else needs resolving |
|
You need to add a couple of |
|
I've tweaked this a bit, I think it's pretty close now. Will review properly tomorrow 🙂 |
|
Hey thank you so much for the small fixes that I missed! They’re much appreciated. I’ll add in the diff and update the change log in a bit. |
Codecov Report
@@ Coverage Diff @@
## master #7968 +/- ##
========================================
Coverage ? 64.7%
========================================
Files ? 256
Lines ? 10051
Branches ? 1497
========================================
Hits ? 6504
Misses ? 3223
Partials ? 324
Continue to review full report at Codecov.
|
| uid?: number; | ||
| gid?: number; | ||
| }; | ||
| export {ForkOptions}; |
| } | ||
|
|
||
| export interface Global { | ||
| export interface Global extends NodeJS.Global { |
There was a problem hiding this comment.
I didn't know this was the fix. I tried extending the global inside the declare. Cool beans.
| * LICENSE file in the root directory of this source tree. | ||
| */ | ||
|
|
||
| import EventEmitter from 'events'; |
There was a problem hiding this comment.
Should this be import * as EventEmitter from 'events' ?
There was a problem hiding this comment.
It's the same object
$ node -p "require('events') === require('events').EventEmitter"
trueAnd the node docs does not destructure: https://nodejs.org/api/events.html#events_events
There was a problem hiding this comment.
My concern is that events may not has a default export just like path.
import path from 'path' won't work on ts.
There was a problem hiding this comment.
Fair point! Changed. Should we add "allowSyntheticDefaultImports": false to out tsconfig?
There was a problem hiding this comment.
That would conflict with esModuleInterop: true. I think we need it for now, but in an ideal world in the future where everything is written in ESM we will be able to drop esModuleInterop
There was a problem hiding this comment.
Anyways, this PR is not the right place to discuss it. Might be worth a new issue, though, so we do it correctly
There was a problem hiding this comment.
esModuleInterop doc: "Emit __importStar and __importDefault helpers for runtime babel ecosystem compatibility and enable --allowSyntheticDefaultImports for typesystem compatibility"
There was a problem hiding this comment.
Yeah, but that doesn't mean I can't disable it again, does it?
There was a problem hiding this comment.
Might be possible to, but it seems like that would mean to forbid default-importing module.exports for type checking, but including the interop helper in output code. Because we use Babel, so our tsc does not emit anything, that would equal not enabling either of them at all, I think. And I believe we need it at least for default-importing some util libraries from npm that use module.exports =
There was a problem hiding this comment.
Anyways, this PR is not the right place to discuss it. Might be worth a new issue, though, so we do it correctly
😀
0f7b761 to
01485d4
Compare
This reverts commit 266a8c9.
|
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. |
This PR migrates jest-runner. I need help on some things hence opening an early PR
Heres the diff
Details