Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

incorrect TypeScript definitions for TelephoneNumber, Extension, PhoneCode

See original GitHub issue

EDIT: it turned there was serious downside with this change i proposed bellow


Currently PhoneCode (and TelephoneNumber and Extension) are defined using interface, like: export interface PhoneCode extends String { } meaning, that variables/fields of these types are treated as objects, not string primitives (even tough typeof phoneCode === "string").

As a result variable of type PhoneCode can’t be assigned to variables/fields with string type:

import { getPhoneCode } from 'libphonenumber-js';

const phoneCode = getPhoneCode('EE');
const phoneCodeAsString: string = phoneCode;
// ERROR:^^^^^^^^^^^ TS2322: Type 'PhoneCode' is not assignable to type 'string'.

Expected behaviour

Should be able to asign PhoneCode (and TelephoneNumber and Extension) to ´string´.


Declare PhoneCode (and TelephoneNumber and Extension) using export type XXX = string instead of export interface PhoneCode extends String { }

Just in case, I’m mentioning @RonNewcomb, because he created the initial TypeScript definitions file, and also @catamphetamine who has created Extension type by following example of @RonNewcomb

Issue Analytics

  • State:closed
  • Created 6 years ago
  • Reactions:2
  • Comments:21 (13 by maintainers)

github_iconTop GitHub Comments

jineshshah36commented, Jun 12, 2018

I would like to suggest potentially reopening this issue. Idiomatic Typescript favors just using the “string” type instead of extending “String”. Most people using Typescript will expect the simple string type. Extending String should be left to the user and not required for everyone having to use the library. In most cases, the rest of the program will expect to consume the value as a regular string type. You are making a big assumption that people need to know the difference between CountryCode and TelephoneNumber at the type level. If they do, it should be on them to enforce that.

RonNewcombcommented, Feb 5, 2018

The assignment needs a cast: const phoneCodeAsString: string = <string>phoneCode;

The problem with Typescript’s export type XXX = string syntax is that the Intellisense of every IDE I’ve ever seen will show a var/property of type XXX as being of type string, not XXX. That largely defeats the purpose of typing it at all. (I believe the syntax doesn’t actually make a new type; it’s just a shortcut to save typing. Hence it doesn’t throw type mismatch errors.)

The reason that requiring a cast is (IMHO) a good thing is such: If you have an Address1 type descended from string and a CustomerName type descended from string, and you assign a value of one to a property/var of the other, you want to get the compiler error that requires a cast, because they’re different types despite both being represented as string.

This problem is particularly acute with string manipulation libraries like this one. Strings in, strings out, did this string already go through the library or not, does the phone# format that that string is in match the format that this string function accepts… everything’s a damn string. You’re effectively working with untyped data since string is about as helpful in this context as any.

Making subtypes that appear in intellisense helps a lot with simple usability, and the occasional required cast, albeit annoying, can save a you a bug hunt or two next week.

But yeah I really wish Typescript would realize that var supertypeVar = subtypeValue is a valid no-cast-required assignment by OO rules.

Read more comments on GitHub >

github_iconTop Results From Across the Web

libphonenumber-js - npm
Returns phone number type (fixed line, mobile, toll free, etc) or undefined (if the number is invalid or if there are no phone...
Read more >
Bad Practices on Phone Number Form Fields - UX Movement
Users may make the mistake of typing in their country code when it's not required, resulting in an incorrect phone number.
Read more >
4.2. Validate and Format North American Phone Numbers
You want to determine whether a user entered a North American phone number, including the local area code, in a common format.
Read more >
Regular expression to match standard 10 digit phone number
If you are trying to do this, you are probably doing it wrong. Phone numbers are of varying lengths, include different country codes...
Read more >
How to build international phone number input in HTML and ...
164 which combines country codes and subscriber numbers in a format like this: +14155552671. This format is required by many APIs (including ...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found