-
Notifications
You must be signed in to change notification settings - Fork 24
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
Add type checking for codecov metrics #3148
Merged
Merged
Changes from all commits
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
Instead of creating an object here, can we just export the different metrics as
const's
? Using objects like this stop some minification optimizations from happening because you can't shorten names on field properties for objects, instead just exporting theconst's
directly.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.
You can pre-face them with
METRICS_
to better identify them.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.
It's a tradeoff, in Rohit's approach the optimization is being traded off for a better auto-complete experience in the IDE.
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 prefer to use a single object as a source of truth for all metrics as it is more structured that way. IMO the benefits from readability and accessibility of the structure outweigh any minification optimizations on a few lines, given just a small number of constants.
Happy to make the change if you think there are any practical performance concerns from not doing this.
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.
Giving this a bit more thought, I think we should take a slightly different approach then both the current implementation and my original suggestion, my original reasoning isn't all that great.
I think we should remove the object entirely because it's introduces a lot of duplicate code both the key and value are always the same, and using the object that way also introduces the possibility that only one side of the key or value is changed but not the other, making this code brittle.
The approach I think would solve all the concerns and be very ergonomic is to create a union type and just use string literals in place. Right now the typeahead will only work after you imported the object, whereas with a type union it works instantly after you open a leading quote.
Here's an example of what the union type would look like:
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.
Similarly, we can utilize TS enums here if we want something similarly ergonomic.
https://www.typescriptlang.org/docs/handbook/enums.html#enums-at-compile-time
This example is somewhat of a middle ground between both of your approaches, just a little easier for me to read personally without all the '|' as we add more metrics but also not as verbose as setting the keys and values to the same thing
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 add some comments around the enum, to inform people to not actually ever use the enum directly. There are quite a few gotcha's with enums, that we want to avoid at all costs so we don't want people to accidentally use it and cause larger issues.
You can read more about the issues with enums, and I personally think we should avoid them, "Why I Don't Like Enums", but I'm okay with using them as long as we don't export them and just use them to build out the string literal unions
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.
These are good points, but I think for a change a small as this, how we choose to implement it will have a negligible effect on performance or any other meaningful metric.
I will merge this change as is later today unless we think there is a strong practical reason to go with one approach over the other.