-
-
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: update type definitions for coverageReporters #10275
Conversation
Hi @not-a-doctor! 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 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 to sign the corporate CLA. If you have received this in error or have any questions, please contact us at [email protected]. Thanks! |
f37b3c2
to
b057851
Compare
Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks! |
docs/Configuration.md
Outdated
@@ -193,7 +193,7 @@ Indicates which provider should be used to instrument code for coverage. Allowed | |||
|
|||
Note that using `v8` is considered experimental. This uses V8's builtin code coverage rather than one based on Babel. It is not as well tested, and it has also improved in the last few releases of Node. Using the latest versions of node (v14 at the time of this writing) will yield better results. | |||
|
|||
### `coverageReporters` [array\<string | [string,any]>] | |||
### `coverageReporters` [CoverageReporters] |
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.
This type is not defined in the docs, do you think it'll be confusing for users?
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 did hesitate a bit editing this line because of the reason you've mentioned. I then searched docs and here in the file we also have a ProjectConfig type in a signature and as "projects" config field definition, although it is not "defined" itself.
Several combinations of options shape make it tedious to list and not pleasant to maintain; and [string, any] type is not quite correct as we are about to become limited to these shapes. While I decided to use the custom TS type, it still is not terrible to leave it as it were before, imo. So what do you think?
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.
We could link to the types (code)?
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.
thanks for the tip, done.
b057851
to
bc517c1
Compare
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.
Can you update the versioned docs as well?
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
Typing the config object as Config.InitialOptions resulted in error, because coverageReporters property in Config.InitialOptions was listed as an array of strings.
Test plan
Since there is only a change in typing precision, there is none.