Conversation
The validation for when to colorize or not was happening in a loop. Instead, it is now done once up front instead.
|
I think the side effect is that the input is no longer validated when colorize is disabled |
|
@marco-ippolito yes, that is correct. It is the question if we need to validate the colors if they are not used. |
I lean more on the yes we should always validate the input (that's why when I previously worked on this api I left the check in the loop) but I really dont have a strong opinion, just wanted to highlight this change |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #60133 +/- ##
==========================================
+ Coverage 88.52% 88.53% +0.01%
==========================================
Files 703 703
Lines 207825 207807 -18
Branches 40003 40008 +5
==========================================
+ Hits 183976 183992 +16
+ Misses 15862 15815 -47
- Partials 7987 8000 +13
🚀 New features to boost your workflow:
|
|
I'm still not convinced the performance improvement is worth making this api behave differently depending on the environment. |
|
@marco-ippolito is that a hard blocker? I think this is an improvement, since a lot of environments will not use colors while they will very likely check during implementation that things work as expected with colors. |
|
Not a hard blocker, maybe we should document it? |
There was a problem hiding this comment.
I discussed with @BridgeAR at jsconf jp about this PR. Blocking to make sure it doesnt land without resolving my points
The validation for when to colorize or not was happening in a loop. Instead, it is now done once up front instead.