I'd do:
- did input start with a +? Then it really isn't a local number.
- else if parse && isValidNumber - continue - we're already good.
- else if isPossibleNumber is true - try prepending area code. If now isValidNumber says true, win! If not, but isPossibleNumber says true still, then it could still be right but maybe validity data is out of date.
To pick a winner in this case where number with or without area code is never valid but always possible, you could get the national prefix for a country and see if the normalized number starts with that.
-- getNddPrefixForRegionCode(region, true)
-- normalizeDiallableCharsOnly(local_number)
Then test if the normalized string starts with the national prefix.
Indeed there are two sad cases one has to be aware of. If it's mobile and from Mexico or Argentina we need to add the mobile token too. For Argentina you can add a 9 at the start if the area code doesn't start with 0, or else 15 between area code and local number. For Mexico just stick a 1 in front.
Clients shouldn't have to know this though!!
We could write a function to do this, but then you'd have to pass in "isMobile" and you might not even know this.
Ideally, parse() would know and fix this so you could just naively always concatenate the two. We have an outstanding feature request to do this and even for MX at least have the data; we might have it for AR too. However it's complex.
So short term you'll have to special-case those two countries, sorry!!!
(Note if you don't know if the number is mobile, we can't currently help you for these two countries. However, if you get it wrong and don't include the mobile token many things will still work because a lot of carriers will fix it for you.)