TypeScript-DOM-lib-generator
TypeScript-DOM-lib-generator copied to clipboard
Attempt to add interface for constuctors to add static properites
OK, this PR is a headache and a trip down the rabbit hole for me. It's technically a broken PR as I know one test fails, but I can't fix it without input on how.
Long story short, I'm working with a team to develop a types package for a framework (I guess that's the best way to put it, Foundry VTT for the interested), and in there they patch in a number of static and instance methods to built in objects (not ideal, but we have don't have control on this).
This was fine for most things to add static methods to things like Array
and Number
which had ArrayConstructor
and NumberConstructor
as ways to extend the constructor's types. Totally fine, up to this point. Then they added a static method for URL
and URLConstructor
does not exist. My temp fix locally was to manually redefine the URL
variable instance since it's a type rather than an interface and slap a @ts-expect-error
comment on it for now, but I figured this is something that could be fixed up stream and give everything I can a constructor interface.
Good news, I did that, works just fine for almost everything. Bad news, broke a single test because of a snowflake. So much for a simple PR to make things better. My simple patch does generate for URL (and others) the same style of constructor interface for type merging, worked for all but AudioWorkletProcessor
, as it already has AudioWorkletProcessorConstructor
defined.
unittests/files/audioworklet/usage.ts:3:17 - error TS2510: Base constructors must all have the same return type.
3 class extends AudioWorkletProcessor {
~~~~~~~~~~~~~~~~~~~~~
Found 1 error in unittests/files/audioworklet/usage.ts:3
Now the "offending" bit is defined here https://github.com/microsoft/TypeScript-DOM-lib-generator/blob/804bc3b7763497ef9eecb180773b56ba21480f0a/inputfiles/overridingTypes.jsonc#L406-L410. This starts to open a larger can of worms than I can reasonably try to keep a lid on. Reading this at least fills me in on why AudioWorkletProcessorImpl
exists to deal with the process
method.
I leave this here in a vague hope that my last 4 hours of head scratching, poking, and prodding to find out why URLConstructor
did not exist while trying to add it in helps somewhat.
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.