feat(isRgbColor): add allowSpaces option to allow/disallow spaces between color values#2029
feat(isRgbColor): add allowSpaces option to allow/disallow spaces between color values#2029rubiin merged 21 commits intovalidatorjs:masterfrom
allowSpaces option to allow/disallow spaces between color values#2029Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #2029 +/- ##
==========================================
Coverage 100.00% 100.00%
==========================================
Files 108 104 -4
Lines 2482 2215 -267
Branches 627 481 -146
==========================================
- Hits 2482 2215 -267 ☔ View full report in Codecov by Sentry. |
| 'rgba(255, 255, 255, 0.5)', | ||
| ], |
There was a problem hiding this comment.
I think it's worthwhile to add a test case like this for clarity's sake:
| 'rgba(255, 255, 255, 0.5)', | |
| ], | |
| 'rgba(255, 255, 255, 0.5)', | |
| 'r g b( 0, 251, 222 )', | |
| ], |
There was a problem hiding this comment.
changed so that it does not ignore spaces between rgb at start, and added the test cases
| const rgbaColor = /^rgba\((([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5]),){3}(0?\.\d|1(\.0)?|0(\.0)?)\)$/; | ||
| const rgbColorPercent = /^rgb\((([0-9]%|[1-9][0-9]%|100%),){2}([0-9]%|[1-9][0-9]%|100%)\)/; | ||
| const rgbaColorPercent = /^rgba\((([0-9]%|[1-9][0-9]%|100%),){3}(0?\.\d|1(\.0)?|0(\.0)?)\)/; | ||
| const startsWithRgb = /^rgba?/; |
There was a problem hiding this comment.
Why did you add this? Isn't it already checked in the first section of the other regexes?
There was a problem hiding this comment.
Ah, I see. It's because the newly added test is invalid. Why is that?
There was a problem hiding this comment.
so that we can check that it does not haves spaces between r g b and a only for the rest of the string
There was a problem hiding this comment.
I figured 'r g b( 0, 251, 222 )' failing validation but 'rgb( 0, 251, 222 )' passing is more inline with what an rgb color string is
|
Could it be useful to have a Strictness has come up a few times before, and there is an ongoing process with the ISO8601 validator which stems from people expecting different levels of strictness (the ISO8601 standard includes a lot of different formats, but people often want only one specific timestamp format). |
it's possible to add a boolean parameter and switch between old and new behaviour. My intent was just to resolve the issue faced in #2028 |
I think that is the safest approach. If we want to avoid breaking changes, the function should take an options object that defaults to Personally I would lean towards having it default to false and just do a major version bump. It just makes more sense that it is lax by default and you have to actively make it stricter. In that case you should write a clear descriptor of what the breaking change entails. I suggest changing the title of the PR to |
|
I agree that we want the default to be false, but I think we can go forward with this PR with |
Perhaps it is more elegant to make a PR for that right away and state in the title that it should be merged for the next major version. It's easy to forget TODOs deep in the source code. |
|
Making a second PR right after this is merged to keep for the next major release would indeed be better. Good point! |
So is this PR good to go? |
src/lib/isRgbColor.js
Outdated
| const startsWithRgb = /^rgba?/; | ||
|
|
||
| export default function isRgbColor(str, includePercentValues = true) { | ||
| export default function isRgbColor(str, includePercentValues = true, strict = true) { |
There was a problem hiding this comment.
I would use an options object here instead of individual arguments.
I think something should be done so that the function will be backwards compatible. There are examples of this somewhere in this repo, but I don't remember exactly where I've seen it
There was a problem hiding this comment.
We should indeed make includePercentValues backwards compatible if we move to an options object (which has my preference as well, see #1874 ). An example for this is;
validator.js/src/lib/isLength.js
Lines 8 to 14 in 86a07ba
There was a problem hiding this comment.
is something like 301e707 what you had in mind? 🙂
There was a problem hiding this comment.
We don't want to present both ways of providing options in the readme. Just describe the object parameter. The backwards compatibility is just there to avoid breaking changes for existing codebases. I don't think we should actively promote the old (inferior) way.
src/lib/isRgbColor.js
Outdated
| options.includePercentValues : true; | ||
| } else { | ||
| // backward compaitable behaviour | ||
| // Defaults |
There was a problem hiding this comment.
I agree, we should have the object as the default behaviour. That makes the most sense to me.
There was a problem hiding this comment.
@a-h-i I still think it's worthwhile to flip the logic here and put the object in the else clause
Co-authored-by: Brage Sekse Aarset <brage.aarset@gmail.com>
Co-authored-by: Brage Sekse Aarset <brage.aarset@gmail.com>
Co-authored-by: Brage Sekse Aarset <brage.aarset@gmail.com>
Co-authored-by: Brage Sekse Aarset <brage.aarset@gmail.com>
Co-authored-by: Brage Sekse Aarset <brage.aarset@gmail.com>
This reverts commit 4c31a86.
This reverts commit 3f05aa5.
This reverts commit 09d9e95.
Co-authored-by: Brage Sekse Aarset <brage.aarset@gmail.com>
|
@profnandaa rebased and resolved merge conflicts |
profnandaa
left a comment
There was a problem hiding this comment.
LGTM, thanks for your contrib! 🎉
|
@WikiRik hey, sorry for the ping, I was wondering does it require another review? A bit unclear on the process from here |
@profnandaa will merge this one soon and then it should end up in the next release |
|
@rubiin -- can take a look at this again? looks like it was good to go? |
isRgbColor now behaves in a similar manner to HSL, and ignores spaces. fixes #2028
Stripped spaces in isRgbColor function
Checklist