-
-
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
chore: migrate jest-worker to TypeScript #7853
Conversation
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.
Tried really hard to stay focused despite the huge diff, and found at least a few nits / questions 😅
// Because of the dynamic nature of a worker communication process, all messages | ||
// coming from any of the other processes cannot be typed. Thus, many types | ||
// include "any" as a flow type, which is (unfortunately) correct here. | ||
// include "unknown" as a TS type, which is (unfortunately) correct here. |
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.
Eagle eye 😄
}; | ||
|
||
export type ChildMessageInitialize = [ | ||
typeof CHILD_MESSAGE_INITIALIZE, // type | ||
boolean, // processed | ||
string, // file | ||
?Array<mixed>, // setupArgs | ||
?MessagePort, // MessagePort | ||
Array<unknown> | undefined, // setupArgs |
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.
Intentionally left out null
? I see ChildMessageInitialize
being assigned from any
and usually we have null
s in this package
Edit: I guess for an array leaving out the element makes more sense though. On a side note, wondering if TS differentiates between [string | undefined]
and [string] | never[]
. Would matter for inferring the parameter type of forEach
😄
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.
yea, mostly because it didn't complain. the less allowed values the better, IMO. Easy enough to add more allowed types at some point if there's value in it
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.
Tried out the side note thing in the TS playground btw, looks like it does differentiate 😎 not relevant for our use case though
@@ -63,7 +61,7 @@ it('passes fork options down to child_process.fork, adding the defaults', () => | |||
}); | |||
|
|||
expect(childProcess.fork.mock.calls[0][0]).toBe(child); | |||
expect(childProcess.fork.mock.calls[0][1]).toEqual({ | |||
expect(childProcess.fork.mock.calls[0][2]).toEqual({ |
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.
Wait what :D
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 typings doesn't allow skipping the args
array. It's not mentioned in the docs, so probably fine
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.
Oh, totally missed the added []
^^
Co-Authored-By: SimenB <sbekkhus91@gmail.com>
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 left the tests alone as there were way too many typer errors for the effort I wanted to put into it :P
At some point we can probably make the types smarter (having it infer exports from the file coming in, filtering by
exposedMethods
etc). My hope is that someone will contribute that as a PR at some point 😀built diff:
Test plan
Green CI