Improve URLSearchParams constructor type definition

[rossrobino]

Overrides the type of URLSearchParams init to accept a Iterable<[string, string]> instead of string[][].

MDN Reference

For example:

new URLSearchParams(new Set([["name", "ross"]]));

is valid, but currently shows an error.

There was an added type of URLSearchParams which I figured I should remove, the Iterable<[string, string]> type covers this case as well.

[rossrobino]

@microsoft-github-policy-service agree

[github-actions[bot]]

Thanks for the PR!

This section of the codebase is owned by @saschanaz - if they write a comment saying "LGTM" then it will be merged.

[jakebailey]

I can't seem to get it to generate, I'm getting a ENOENT error. I don't have files in /inputfiles/mdn/

You need to have cloned the submodule as well.

git submodule update --init

[saschanaz]

This is blocked by #222 because vars can't be split by separate type declarations. We cannot just override the constructor because it'll break ES5 compatibility.

https://github.com/microsoft/TypeScript/issues/3538 could greatly help without all those separate libs but I don't see that coming anytime soon.

[jakebailey]

ES5 is going to be deprecated, so maybe there's a future where it'd work out.

[rossrobino]

Thanks @jakebailey, got it to generate and committed the changes.

I am seeing the Cannot find name 'Iterable' error now during the test run, I assume this is the ES5 issue. Let me know if not!

[jakebailey]

Correct, but we're likely making DOM imply ES6 and DOM.Iterable in 6.0

[saschanaz]

But will 6.0 remove ES5 completely?

[jakebailey]

As a target for emit, yes, at least deprecated.

The rest is more a product of us wanting to make DOM.Iterable auto included, but that means we need Symbol, which means ES6, or at least the es6 symbol libs. It isn't really clean to do, so still figuring it out.

[jakebailey]

Actually, why isn't this being stuck into the iterable d.ts file?

[rossrobino]

I can add or feel free to edit as well! I'm not sure exactly which file you are referencing. Should it be added to the generated file here as the call signature? https://github.com/microsoft/TypeScript-DOM-lib-generator/blob/main/baselines/dom.iterable.generated.d.ts#L400

[saschanaz]

Actually, why isn't this being stuck into the iterable d.ts file?

Because we can't override constructors without having #222 first.

[jakebailey]

For 6.0, we're going to make the DOM types reference ES6/ES2015 (and promote DOM.Iterable to just being DOM), so we could probably just wait a bit and this will all be a non-issue.

Though, why isn't this a Constructor type instead of a named interface that can be merged into, like we do Map and such?

[saschanaz]

You mean defining a separate interface? Because that'll pollute the global namespace 2x than we do now...

[jakebailey]

Yes, since that's what we do in the main libs, but I suppose that would be pretty noisy.

[jakebailey]

In any case, I think we should shelve this temporarily, at least until I put together a PR for this repo to introduce a 6.0 variant that makes the iterable/es2015 change.

[Renegade334]

It should be possible to implement https://webidl.spec.whatwg.org/#js-sequence in the builder and map all sequence function parameters to Iterables in 6.0, so individual PRs shouldn't be necessary anyway.

[jakebailey]

In any case, I think we should shelve this temporarily, at least until I put together a PR for this repo to introduce a 6.0 variant that makes the iterable/es2015 change.

This time has come; TS 6.0 now pulls in iterable/asynciterable.