inconsistent parse result when using National vs International number

[aitboudad]

parse('0569887076', 'MA')
// result: { "country": "MA", "phone": "569887076" }

parse('+212569887076')
// result: {}

The number is not valid but it can be parsed see https://libphonenumber.appspot.com/phonenumberparser?number=%2B212+569887076

[catamphetamine]

Try the latest version and reply here

…

On Tue, 6 Feb 2018 at 21:58, Abdellatif Ait boudad ***@***.***> wrote: parse('0569887076', 'MA')// result: { "country": "MA", "phone": "569887076" }parse('+212569887076')// result: {} The number is not valid but it can be parsed see https://libphonenumber.appspot.com/phonenumberparser?number=%2B212+569887076 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#176>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAdH77byHy73jAgzxyn1m4RWjDAZt8fDks5tSKDNgaJpZM4R7jn5> .

[aitboudad]

I'm using the latest version "^1.0.13"

[catamphetamine]

Oh, ok, didn't recognize you from the previous issue.
Well, yeah, the phone number can be parsed and is a possible number but the country is undefined.
See Google's demo: the region is empty.
What could parse do in this case?
It could return countryPhoneCode instead of country, for example.
It would return { countryPhoneCode, country, phone }.
It can't be done in the current version because it could break someone's code.
It could be done in the next major version though.
Or a separate function could be created, like parsePossibleNumber(text), because otherwise parse() would be too complicated.
On the other hand, how would one choose between them.

[catamphetamine]

Updated my comment.
So, maybe it would make sense, still Google only gives countryPhoneCode and nationalNumber in this case and doesn't even format it in E164 format.
This library could be less strict and still could format { countryPhoneCode, country, phone } in E164 without checking phone number validity.
I'm not sure yet what should be done here.

[aitboudad]

why not just adding countryCode to the result { countryCode, country, phone } ?
if region is empty then we leave country empty

[catamphetamine]

Because it seems like a separate scenario from what parse() normally deals with.
The scenario is that a developer grabs a phone number in international format somewhere (e.g. crawls a web page): x+7 111-222 33 44z.
This text would get parsed as +71112223344.
The only result Google's demo gives in this case is { countryPhoneCode: '7', phone: '1112223344' }.
What would one do with such an input.
The only way of using such an input seems to be formatting this number in E.164 for storing in a database.
Google's demo doesn't allow doing that for some reason but this library could allow it being less strict.
In this case the only scenario when such advanced functionality would be needed is parsing a possible (and most likely invalid) E.164 phone number from text.
A separate function for that would have sufficed: something like parsePossibleNumber(text) returning a E.164 if a phone number is a possible one (but it's still most likely gonna be invalid).
Do you need such a function?

[catamphetamine]

On second thought, there are also cases when parsing local numbers for a given country could return ones which are possible but not valid.
In this case a special option passed to parse() would be more appropriate.
E.g. parse('1112223344', 'RU', { possible: true }) would return { country: 'RU', phone: '1112223344', possible: true }.
Perhaps I'll implement it that way.

[catamphetamine]

I experimented with "possible" numbers parsing and the new version is released with an undocumented feature:

• (experimental) Added { possible: true } option for parse() for parsing "possible numbers" which are not considered valid (like Google's demo does). E.g. parse('+71111111111', { possible: true }) === { countryCallingCode: '7', phone: '1111111111', possible: true } and format({ countryCallingCode: '7', phone: '1111111111' }, 'E.164') === '+71111111111'.

Perhaps this can become an official feature some time after.

[catamphetamine]

I released the new version with "possible" numbers feature.
See the updated readme for parse().

Available options:

• defaultCountry : string — Same as defaultCountry argument.

• extended : boolean — If set to true then parse() will attempt to parse "possible" phone numbers even if they're classified as "invalid". The result of "extended" parsing has shape { country, countryCallingCode, phone, ext, valid: boolean, possible: boolean }; some or all of these properties may be absent. The "extended" parsing is the default behaviour of the original Google's libphonenumber: it still returns parsed data even if the phone number being parsed is not considered valid (but is kinda "possible"). Though I don't know who might need such an advanced feature, still it has been requested and therefore has been implemented.

[catamphetamine]

Demo has been updated
https://catamphetamine.github.io/libphonenumber-js/

[aitboudad]

Thanks sound good now!