Repository navigation
Make things as optional when at least one engine lacks support #998
Description
From #837 (comment).
Currently we add types when at least two browser engines add supports, but that doesn't mean it's available everywhere. Making such types as optional may help devs to feature test as needed.
What do you think? Orta Therox (@orta)
Activity
orta commentedon Mar 29, 2021
I think it's more ergonomic to assume it's there, even if it isn't. IMO, we probably shouldn't default to optional.
Perhaps a more general solution is that be that the compiler doesn't raise when you make checks against existing functions which were originally defined in the DOM?
saschanaz commentedon Mar 29, 2021
That also sounds good.
Bashamega commentedon Oct 29, 2025
Hello Kagami Sascha Rosylight (@saschanaz), Jake Bailey (@jakebailey)
This is an important issue, because most people don't check the compatibility list.
I think a better solution is to annotate these classes with something that indicates they are still in development. For example, we can use the
@alphaor@betatagsaschanaz commentedon Oct 31, 2025
In an ideal world there would be a babel-like feature in TS compiler that would hide things based on user expectation config. If that comes in reality then we wouldn't need to manually hide things based on BCD...
Bashamega commentedon Oct 31, 2025
My proposal is a patch until typescript implements this.
Do you think there is a better way to handle this right now?
saschanaz commentedon Oct 31, 2025
Custom tags wouldn't affect the compiler in any way, no?
Bashamega commentedon Oct 31, 2025
Custom tags won't affect it.
It will be just like
@deprecatedAnd people who want to make sure their code works on all browsers can use an ESLint plugin.
saschanaz commentedon Oct 31, 2025
@deprecatedis not a custom tag but a documented one: https://www.typescriptlang.org/docs/handbook/jsdoc-supported-types.html#deprecatedBashamega commentedon Oct 31, 2025
I didn't know this. Maybe choose a tag from the list.