feat(isDate): Disallow mismatching length for isDate

[frederike-ramin]

Before this, if I provided a format to the isDate function, it was never checked that the format exactly matches - including the length of the date. I could have provided any possible date as long as I only included valid delimiters. Important: I only changed this for strictMode because I think there it should 100% be checked, but maybe there are cases (without strictMode) where it is okay? If you want me to remove the strictMode condition, just let me know.

Checklist

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

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 99.95%. Comparing base (b958bd7) to head (efb3f8f). Report is 32 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #2056      +/-   ##
==========================================
- Coverage   99.95%   99.95%   -0.01%     
==========================================
  Files         107      107              
  Lines        2454     2450       -4     
  Branches      619      620       +1     
==========================================
- Hits         2453     2449       -4     
  Partials        1        1              

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[braaar]

In my opinion, that option should be renamed to strict, in line with other validators. We can maintain backwards compatibility by also allowing strictMode, but the documentation should only mention strict

[braaar]

The comment from @braaar is valid, but for a future PR. This PR looks good to me

Perhaps it's reasonable to leave behind a TODO-comment in that case?

[WikiRik]

Perhaps it's reasonable to leave behind a TODO-comment in that case?

That might be good. isMobilePhone also contains strictMode but we'll pick that up as part of #2124 so no need to put a TODO there

[frederike-ramin]

@WikiRik any progress on this? Do we need another review? I now want to include the same thing in another project, so the topic is on the top of my mind again.

[WikiRik]

That's up to @profnandaa