navigator.vibrate is typed as always being defined, but is undefined in Safari

[FuXiuHeng]

The navigator.vibrate API is currently always defined. However, according to the navigator.vibrate MDN docs, this is currently not supported in Safari:

I'm proposing to update the Navigator interface to:

interface Navigator {
    // Proposed change from being required to being optional
    vibrate?: (pattern: Iterable<number>) => boolean;
}

[orta]

Yeah, I agree, this is probably the right call (having made this exact mistake myself also)

[HolgerJeromin]

https://github.com/microsoft/TypeScript-DOM-lib-generator#why-is-my-fancy-api-still-not-available-here
We have the policy to need two js engine support.
Perhaps an API with only two engines chould be marked as optional...

[saschanaz]

Yeah, I'd like to have some policy rather than doing special treatment to a specific API.

[orta]

Hah, yeah, you're both not wrong there - should probably not do it

[saschanaz]

Oh I mean, I'm open to this but I'd like to modify the policy so that things can be consistent for other APIs too.

That said, not sure how the impact would be.

[HolgerJeromin]

Yeah, my suggestion was to make it optional in the emitter code (where we handle the number of implementations anyway).

That said, not sure how the impact would be.

This would probably make quite a few APIs optional with some breakings... Some good, some bad (depending on the target audience of the customer code)

[orta]

Yeah - while I don't think this is a massively used API, I'm willing to bet that systemically making a bunch of fns optional because it's only two is probably going to /feel/ like too much of a breaking change

Hard to say without someone showing a .d.ts diff though

[RyanCavanaugh]

I think our longstanding policy of marking things as fully present once they're in the relevant spec plus two major browsers is a sensible one, Safari's eccentricities notwithstanding. I realize Safari isn't exactly niche, but "a browser that exists doesn't support a spec'd, otherwise-available API" is not a road that goes to a good place.

[guillaumebrunerie]

I've been bitten by that before as well (with requestIdleCallback, which is also not available in Safari). But I'm not sure making it optional is the right decision either, ideally you would rather use a polyfill and then it's not optional anymore, rather than testing for its existence every time you want to use it. But I wish there were a way to remind us of which polyfills we may need to add.

[HolgerJeromin]

Perhaps https://github.com/amilajack/eslint-plugin-compat could be an alternative.
But I have not tested it.

[guillaumebrunerie]

eslint-plugin-compat looks interesting, unfortunately it has some pretty serious issues like exempting everything inside an if statement and not supporting some APIs like requestIdleCallback. For instance the following code does not trigger it at all, even though it would crash twice in Safari:

window.requestIdleCallback(() => {});

const shouldVibrate = true;
if (shouldVibrate) {
    navigator.vibrate();
}

[KieranP]

Coming over from #2142 . I encountered a similar issue with startViewTransition. It's not available in Firefox, but TypeScript shows it as available, even though it would error in production. It also means that using a safety check like if (!document.startViewTransition) return results in triggering TSLints @typescript-eslint/no-unnecessary-condition.

I highly recommend that types should use Baseline status in determining what a type should be. If an API is not yet Baseline Wildly Available, it should probably be typed as possibly undefined. Making this change would align with the current movement to use Baseline as a feature availability status (used by MDN, CanIUse, etc).

[guillaumebrunerie]

Coming over from #2142 . I encountered a similar issue with startViewTransition. It's not available in Firefox, but TypeScript shows it as available, even though it would error in production. It also means that using a safety check like if (!document.startViewTransition) return results in triggering TSLints @typescript-eslint/no-unnecessary-condition.

I highly recommend that types should use Baseline status in determining what a type should be. If an API is not yet Baseline Wildly Available, it should probably be typed as possibly undefined. Making this change would align with the current movement to use Baseline as a feature availability status (used by MDN, CanIUse, etc).

But then the day it does become Baseline Widely Available, all of your safety checks will start triggering @typescript-eslint/no-unnecessary-condition, as it will not be optional anymore. Isn't it better to have a polyfill instead, so that you can use it anywhere without having to check for its existence every time?