fix(isMobilePhone): Fix wrong dv-MV mobile phone matching (issue #2101)

[pano9000]

Hello,

As reported in #2101, isMobilePhone's dv-MV locale is not matching actually correct mobile phone numbers currently.

See my comments there, which show that that the original RegExp was wrong since it was originally committed, last October:
#2101 (comment)

The new RegExp is now based on the official "numbering plan" document from the Maldives Gov
(I've used the archived wayback machine's link, just in case the "live" document above changes in the future, as they seem to be updating that document regularly. Live version can be found here, dated June 2022, as of today).

In there they describe the following ranges as valid mobile phone ranges:
72X XXXX to 79X XXXX
91X XXXX to 99X XXXX

Further examples can also be found in the comment above.

This PR fixes #2101
I also updated the tests accordingly, as the previous tests of course are not valid either anymore.

Potential room for improvement here (but I feel like that maybe should be a separate PR as it is more a feature maybe?):
Also account for "local formatting" of the number - i.e. it appears to be common to use a space or hyphen, separating the (non international) digits into two blocks, e.g.

• 722 1234
• 723-4567

I'll create a separate PR for this, after this fix has been pulled in

Thank you

Checklist

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

[codecov]

Codecov Report

Base: 100.00% // Head: 100.00% // No change to project coverage 👍

Coverage data is based on head (fba5b32) compared to base (f97e8d4).
Patch has no changes to coverable lines.

Additional details and impacted files

@@            Coverage Diff            @@
##            master     #2109   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files          105       105           
  Lines         2335      2335           
  Branches       586       586           
=========================================
  Hits          2335      2335           

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

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

[braaar]

Are these really valid? It seems strange to have a country code there without any indicator that it is a country code (+ or 00, for example). I couldn't find any examples of numbers like this from your links.

[pano9000]

Thanks for your comment, as you make a valid point.

Strictly speaking:
no, these are not valid phone numbers, if there is no + or 00 in front of the country code.

However, I just tried to stick to the same RegExp style like (most if not almost all) the other phone numbers, which are making the + optional, when you don't set the strictMode option to true.
And I just included these technically invalid phone numbers in the tests as well, to test that this "optional" matching works as well :-)

E.g. random examples from isMobilePhone.js:

• nn-NO currently uses /^(\+?47)?[49]\d{7}$/
• el-GR currently used /^(\+?30|0)?(69\d{8})$/

both of these will match phone numbers without 00 or + as valid.

a big side note on this topic

Generally speaking the isMobilePhone RegExp do not seem to be very constistent altogether in the way the RegExp are matching the phone numbers:

• some are checking for the + as mandatory (regardless of strictMode)
• some are checking for the + as optional
• many do not check for the 00 prefix, which actually should be valid as well
• etc.

There's a whole range of different formats in the isMobilePhone, which IMHO should be made a bit more consistent, across all of the different countries (or locales in this case).

However fixing that would be a whole new thingon its own, which I could try to tackle soon as well - the only problem I see is that there are a lot of unmerged PRs in regards to the isMobilePhone, so I am not sure if I should already try to add my changes or wait until these are added?

[braaar]

That is certainly interesting. I don't use phone validation from this library, so I haven't looked much into that side of things. This should definitely be fixed somehow. Could you post this as a new issue?

[pano9000]

Sure, I'll write something up later today and post as a separate issue, so that we can track this better

[profnandaa]

Sure, let's track this as a separate issue, did you post it? Will definitely be a breaking change but a necessary one.

[pano9000]

@profnandaa yeah, had posted it as #2124

[profnandaa]

LGTM