search

mozilla / webextension-polyfill

A lightweight polyfill library for Promise-based WebExtension APIs in Chrome
Mozilla Public License 2.0
2.75k stars 214 forks source link

Providing types with the package by default #651

Closed Lusito closed 4 months ago

Lusito commented 4 months ago

Hey, I'm the author of the type generator for @types/webextension-polyfill .

There is no other maintainer for @types/webextension-polyfill aside from me and therefore it can be hard to find a reviewer on DefinitelyTyped pull-requests that understands the issues at hand. The latest PR has been in review hell, with reviewers requesting changes and then ignoring the PR after I've replied. After almost 2 months I've just closed the PR and recreated it in the hope, that this time will be better.

Any chance we could ship the types with the package itself instead of using DefinitelyTyped? Maybe even move the generator project to this repository?

Rob--W commented 4 months ago

We are not interested in including the types in this repo. As you can see from the update frequency of the polyfill, it is updated infrequently. We also anticipate that the polyfill will become obsolete relatively soon (see below for details). Even past the end of the polyfill's support schedule, the types can still continue to be useful (as a generic "webextension API" type definition).

The polyfill's primary purpose is to offer extension APIs through a Promise-based API, under the browser namespace.

Firefox and Safari have first-class support for the browser namespace.

Chrome does not support Promise at all in Manifest Version 2, but they have deprecated MV2 and its support may disappear in June 2025 - https://developer.chrome.com/docs/extensions/develop/migrate/mv2-deprecation-timeline

Chrome's Manifest Version 3 supports Promises, under the chrome namespace. It does not support Promise as a return value in runtime.onMessage, but they have expressed support for that at https://crbug.com/1185241 .

Because Chrome already offers a Promise-based API under the chrome namespace (in MV3), a polyfill for that could be as simple as

globalThis.browser ??= chrome;

There are also plans to bring the browser namespace to Chrome, following discussion in the WECG. At that point this polyfill would become a no-op, because it does not modify anything if the browser global already exists.

Lusito commented 3 months ago

Thanks for the detailed explanation.

Providing types without having a package for it wouldn't work with DefinitelyTyped though, so I guess I'll convert my project back to a polyfill project which exports only a single constant. That would also resolve the hassles of getting code-reviews through on DT.

Though as can be seen in https://github.com/Lusito/webextension-polyfill-ts/issues/105, there still seem to be incompatible differences between chrome and firefox aside from the promise based API.