Missing URL constructor definition

[zuzusik]

Currently:

interface URL {
    revokeObjectURL(url: string): void;
    createObjectURL(object: any, options?: ObjectURLOptions): string;
}
declare var URL: URL;

Should be:

interface URLConstructor {
    hash: string;
    search: string;
    pathname: string;
    port: string;
    hostname: string;
    host: string;
    password: string;
    username: string;
    protocol: string;
    origin: string;
    href: string;
}
interface URL {
    revokeObjectURL(url: string): void;
    createObjectURL(object: any, options?: ObjectURLOptions): string;
    new(url: string, base?: string): URLConstructor
}
declare var URL: URL;

URL spec is here: https://url.spec.whatwg.org/#api

[kennysong]

Where is the URL interface currently defined? I can't find it.

[mhegazy]

it is defined in lib.d.ts.

[kennysong]

It doesn't seem to be in lib.d.ts.

[danquirk]

GitHub isn't showing the whole file. It cuts off around 11k lines but URL is defined on line 14455

[mhegazy]

look at the raw view: https://raw.githubusercontent.com/Microsoft/TypeScript/master/bin/lib.d.ts

[myitcv]

@mhegazy - is this simply a case of modifying the lib.d.ts type definition? In which case, are you accepting PRs?

[myitcv]

Actually @zhengbli I see your recent comment

Just out of interest, in general how do you determine support within browsers/Javascript VMs? Is there a definitive reference? Your comment in this instance seems to suggest the check was 'by hand'.

[zuzusik]

Here is the living standard for it https://url.spec.whatwg.org/#constructors
On Oct 9, 2015 2:13 PM, "Paul Jolly" [email protected] wrote:

Actually @zhengbli https://github.com./zhengbli I see your recent comment
#3753 (comment)

Just out of interest, in general how do you determine support within
browsers/Javascript VMs? Is there a definitive reference? Your comment in
this instance seems to suggest the check was 'by hand'.

—
Reply to this email directly or view it on GitHub
#2583 (comment)
.

[zhengbli]

@myitcv the lib.d.ts is generated from a spec file produced by Edge, and we make manual changes if something is not quite right with the spec or it is Microsoft specific. We are trying to keep the changes as compatible as possible. There is not a "definitive reference" per se, it is all open to discussion.

[myitcv]

@zhengbli - thanks, however I was asking about something slightly different. Specifically this comment:

after trying out on various browsers, we found that the constructor of interface URL is not supported in both IE and Spartan

Reading this it sounds like the tests were carried out by hand. I was wondering if in fact there is a definitive reference you use for what functions/etc are supported in each browser?

The MDN pages have a browser compatibility section, but I don't know how up-to-date/accurate these are.

Incidentally, what is "Edge"?

[zhengbli]

Oh, for constructors I just open the javascript console in the browser, and run something like new URL() and see what happens. If it gives me an error message, so apparently it is not supported.

Edge is the new Microsoft browser coming with windows 10.

[zuzusik]

URL constructor is a living standard already. We use it in our code together with polyfill for IE. Is this a reason for not adding it to lib.d.ts that it is not yet supported in IE?

[weswigham]

(Don't forget its public domain polyfill.) It's an exposure of the internals used to drive the browser's File/Blob URL APIs. Chrome and Firefox implement the living standard pretty well, and it turns out to be really useful to have a URL parser when working on the web. Much neater than using an img or a tag, anyway.

[myitcv]

@weswigham agreed.

[zhengbli]

@weswigham @zuzusik using polyfill is a fair point. And as adding a constructor and instance methods is not a breaking change, it might be fine to do that. I'll send a PR to add them. FYI I'm working on open source the script to generate lib.d.ts soon, so later changes could be accepted on that repo.

[mhegazy]

Now that the script is to generate the library is open source, PRs are welcomed. Here is some documentation for adding new types to lib.d.ts: https://github.com./Microsoft/TypeScript/blob/master/CONTRIBUTING.md#contributing-libdts-fixes

[RReverser]

Btw, Edge now support URL constructor - does it mean lib.d.ts can be just regenerated from Edge spec as stated above?

[mhegazy]

We refresh the definition file from that of IE/Edge every few month. we have not done this in a while. @zhengbli has something in the pipeline, not sure if it includes this change though.

[RReverser]

Hmm... wouldn't it be possible to somehow automate this? For example, auto-generate lib.d.ts from WebIDLs?

[mhegazy]

This is what is happening in https://github.com./Microsoft/TSJS-lib-generator. PRs are always welcomed to make the generation more efficient/standard-compliment.

[RReverser]

Oh cool, thanks for the link to the repo! But as for "we refresh the definition every few months" - is there any chance to automate this part (as pre-release script for TypeScript?) so that lib.d.ts would be always up-to-date?

[mhegazy]

These files come from IE/Edge. so we do it when they have a new version available; so we have little control over that. @zhengbli can talk more about the specifics of the next update.. i think he already picked up a new version.

[zhengbli]

We are taking another updates after 1.8, as it is very likely that the changes will be big and break many places. Automating the process is definitely possible, however as the spec files are generated from internal builds of Edge, the APIs may not be available yet in the released version. Therefore it makes more sense to review the changes manually now and reduce the interval of updating the spec files in the future.

[RReverser]

however as the spec files are generated from internal builds of Edge, the APIs may not be available yet in the released version

I don't really see how is that a problem - just because public release of Edge doesn't support some new spec APIs natively, that doesn't mean people don't use those APIs (through polyfills, in other browsers, etc.) and doesn't mean they don't want those definitions as soon as they're available... Or am I missing something?

[mhegazy]

@RReverser, I am not sure i understand the problem or the proposal here.

We have lib.d.ts that is generated from the IE/Edge IDL files. @zhengbli updates they, usually quertelly/semi anally.
These definition files may not contain all APIs, or include addtional non-standard ones, or ones that are not standard-complient, for that, we have three files: https://github.com./Microsoft/TSJS-lib-generator/blob/master/inputfiles/overridingTypes.json, https://github.com./Microsoft/TSJS-lib-generator/blob/master/inputfiles/addedTypes.json and https://github.com./Microsoft/TSJS-lib-generator/blob/master/inputfiles/removedTypes.json that we use to make the output correct.

The PR to add URL constructor for instance is using these fiels, see: microsoft/TypeScript-DOM-lib-generator#44.

so am i missing something?

[RReverser]

or include addtional non-standard ones, or ones that are not standard-complient

Gotcha - this was the part I wasn't aware about and thus asked

Or am I missing something?

(I thought it's just that internal builds contain APIs that are not released yet, but are fully spec-compliant and still could be used for TS; thanks for explanations)

[NekR]

I am on TS 1.8.9 and this is almost April now, haven't you generated new version yet?

[mhegazy]

@NekR, PRs are welcomed. see more information in #2583 (comment)

[zhengbli]

As an update, this issue should be fixed by #7619
We recently took a new drop of the XML spec which has the correct definitions for URL.

[NekR]

Great, thanks for the update.

[pritambaral]

@zhengbli When may we see the fix? The latest release 1.8.10 doesn't have it.

[zhengbli]

It is already in master: https://github.com./Microsoft/TypeScript/blob/35b8b42b554d2b98230320b727b452d0abe9aaae/src/lib/dom.generated.d.ts#L11740

it should be in next release.