USVString type definition

TypeScript Version: 3.2.0-dev.201xxxxx

Search Terms: USVString

Code

function example(uri: USVString) {
    // Do some work
}

Expected behavior: Until typescript version 3.0.3 USVString used to be an existing type defined in lib.dom.d.ts in version 3.1, according to the breaking changes page, some vendor-specific types are removed from lib.d.ts, a full list of removed types is included. USVString is not on that list, yet it’s type definition was also removed.

USVString is defined under webIDL, as can be seen here.

Actual behavior: error TS2304: Cannot find name 'USVString'.

[jimmywarting]

I have been pretty much bothered with the way typescript handles USVString as a String To me they don’t seem to be the same thing

a USVString dose lots of conversion casting mostly anything to a string, it deals with Symbol.toStringTag, toString() and defaulting values by doing something like String(null_or_whatever)

Here are some example

// This works fine and it's totally valid in vanilla js!
async function get (req) {
    const url = new URL(req)
    url.searchParams.set('api_key', '---')
    return fetch(url)
}

TS throws for using fetch in this way…

Argument of type 'URL' is not assignable to parameter of type 'RequestInfo'.
  Type 'URL' is not assignable to type 'string'.

https://github.com/microsoft/TypeScript/blob/cec2fda9a53620dc545a2c4d7b0156446ab145b4/lib/lib.dom.d.ts#L19650

it shouldn’t be a regular string. It should be a USVString instead!

Same thing with blobs! it’s totally legit to do: new Blob([{}]) if you want to do something like this, you could provide a own custom class that has a toString method and have it working

- type BlobPart = BufferSource | Blob | string;
+ type BlobPart = BufferSource | Blob | USVString;

[weswigham]

Our IDL-based generator just interprets USVString as an alias for string, because it effectively is. Do you still need a type USVString = string alias in the lib? The lib itself stopped using it because it was rather pointless.