Added Exact Condition for String Length & Updated README.md

[bevatsal1122]

feat(isLength): Added Conditions for checking if String's length is equal to exact if exact provided

If the string length falls in the range and if exact number/array/object is provided, then exact conditions are checked. If not provided, then true is returned is len>=min & len<=max and false is returned is not in the range [min, max]. README.md File is also updated for the same.

Checklist

• [x] README updated (where applicable)
• [x] PR contains only changes related; no stray files, etc.
• [x] Tests written (where applicable)

[codecov[bot]]

Codecov Report

Patch coverage: 100.00% and no project coverage change.

Comparison is base (531dc7f) 100.00% compared to head (3ef2588) 100.00%.

:exclamation: Current head 3ef2588 differs from pull request most recent head 22bb2f0. Consider uploading reports for the commit 22bb2f0 to get more accurate results

Additional details and impacted files

@@            Coverage Diff            @@
##            master     #2019   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files          104       104           
  Lines         2308      2311    +3     
  Branches       578       579    +1     
=========================================
+ Hits          2308      2311    +3     

Impacted Files	Coverage Δ
src/lib/isLength.js	100.00% <100.00%> (ø)

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

[bevatsal1122]

Hello, I have added the required feature. If the string length falls in the range and if exact number/array/object is mentioned, then exact conditions are checked. If not provided, then true is returned is len>=min & len<=max and false is returned is not in range [min, max]. All the checks have also been passed :) PR#2019 - https://github.com/validatorjs/validator.js/pull/2019

[bevatsal1122]

Thanks for the updates! I have some additional comments

And I'll tag @rubiin here as well for the more official review and approval for having exact be either a number, a array or an object of numbers since I'm not a maintainer of this library

Okkay

[bevatsal1122]

Keep the old test and then I think we should be good. I'll leave other reviews up to the actual maintainers of this library. Thanks again for working on this!

Yess!! The old test is been added again... Anyways, Feeling happy after working on this!! Thank You

[bevatsal1122]

@rubiin @WikiRik @chuyeow @boutell @timoxley Please have the final look.

[WikiRik]

As mentioned before, my review won't help. But it all looks good to me!

[braaar]

As mentioned before, my review won't help. But it all looks good to me!

The woes of being an active contributor without write access 🥲

[bevatsal1122]

@rubiin Please have a final look.

[rubiin]

Before further review lets wait for approval from @profnandaa

[bevatsal1122]

Sorry for late review on this.

I'm struggling to understand the use-case for exact. And also why we have as an object or array too. Could you explain where this could be used?

Instead of just giving users the only feature of passing the minimum and the maximum length of string, if at all a user wants to check if the length of string matches the exact number/s then he can simply pass exact values.

This can be understood by the following use case-

• If the user wants a string length to be exactly 10, then he would have to pass minimum: 10 & maximum: 10 whereas this could be done by simple exact: 10.
• If the user wants to check if the string length matches multiple values, then passing just minimum & maximum values are of no use, instead, he can simply pass an array of integers.

I hope this solves your confusion.

[profnandaa]

@bevatsal1122 -- thanks for the clarification. I'd thought .length will be enough but I guess for the sarogate pairs/some unicode chars, that the function support, this will be handly.

Let me merge, thanks! And thanks too @WikiRik @rubiin for your reviews on this.

[profnandaa]

One more approval and I'll merge. @rubiin @WikiRik

[bevatsal1122]

@pixelbucket-dev I made all the necessary changes and also synced the branch with the latest commits.

[pixelbucket-dev]

I was just thinking: A future improvement could be to improve the options API to have consistent fields. This is because, with discreteLengths, we have a new field, and the API might become less intuitive to use now.

Something like:

{
	range: {
		min: 0,
		max: undefined
	}, // optional
	discreteLengths: undefined // optional
}

With the above proposal, it also becomes clear, that there is another permutation of the rules set:

1. range defined AND discreteLengths undefined ⇒ implemented by this PR
2. range undefined AND discreteLengths undefined ⇒ implemented by this PR
3. range defined AND discreteLengths defined ⇒ implemented by this PR
4. range undefined AND discreteLengths defined ⇒ NOT implemented by this PR

So basically, we would have to discuss if this API should allow checking against discrete lengths w/o using the range rule/option. Currently, to check discreteLengths, min and max, i.e. range, are also considered.

Just some food for thoughts 😄.

[bevatsal1122]

I was just thinking: A future improvement could be to improve the options API to have consistent fields. This is because, with discreteLengths, we have a new field, and the API might become less intuitive to use now.

Something like:

{
	range: {
		min: 0,
		max: undefined
	}, // optional
	discreteLengths: undefined // optional
}

With the above proposal, it also becomes clear, that there is another permutation of the rules set:

1. range defined AND discreteLengths undefined ⇒ implemented by this PR
2. range undefined AND discreteLengths undefined ⇒ implemented by this PR
3. range defined AND discreteLengths defined ⇒ implemented by this PR
4. range undefined AND discreteLengths defined ⇒ NOT implemented by this PR

So basically, we would have to discuss if this API should allow checking against discrete lengths w/o using the range rule/option. Currently, to check discreteLengths, min and max, i.e. range, are also considered.

Just some food for thoughts 😄.

Yeahh that's a really good idea. Making it segregated into key-value pairs would be easier to use and understand. @WikiRik @rubiin What do you think ??

[pixelbucket-dev]

I was just thinking: A future improvement could be to improve the options API to have consistent fields. This is because, with discreteLengths, we have a new field, and the API might become less intuitive to use now. Something like:

{
	range: {
		min: 0,
		max: undefined
	}, // optional
	discreteLengths: undefined // optional
}

With the above proposal, it also becomes clear, that there is another permutation of the rules set:

1. range defined AND discreteLengths undefined ⇒ implemented by this PR
2. range undefined AND discreteLengths undefined ⇒ implemented by this PR
3. range defined AND discreteLengths defined ⇒ implemented by this PR
4. range undefined AND discreteLengths defined ⇒ NOT implemented by this PR

So basically, we would have to discuss if this API should allow checking against discrete lengths w/o using the range rule/option. Currently, to check discreteLengths, min and max, i.e. range, are also considered. Just some food for thoughts 😄.

Yeahh that's a really good idea. Making it segregated into key-value pairs would be easier to use and understand. @WikiRik @rubiin What do you think ??

It would be a breaking change! So I'd suggest keep the existing API (min and max), like with the other PRs here, and add the new fields range and discreteLengths. min and max should probably be prioritised if defined, for now. You can document the new syntax already in this PR and deprecate min and max. With the next major version, min and max will be removed.

[WikiRik]

@rubiin any reason why you approved this while the GitHub Actions have not passed?

[pixelbucket-dev]

@bevatsal1122 could you please fix the formatting issues that break the CI? View the “Files Changed” tab so see details about the linting issues.

N.B. we have to discuss better linter integration. Errors like this should never arrive in the PR, but rather fixed at commit time or push time by running commit hooks.