globals

While investigating why eslint wouldn't pick up the globals, I noticed eslint does not use builtin like I previously assumed. I'd like to propose to copy any globals missing in either , , but present in to one of those respective environments. Afterwards, I'd copy back any potential globals from the categories to so that it ends up containing all globals from those categories. Alternatively, could be generated dynamically in , I think actually, that'd be my preference to avoid future inconsistency.

Hey hey! This is more of a question than a request, and I'm happy to open the PR myself if you think this would fit in the repository. Thunderbird supports the Web Extension API, but encourages using the global instead of the global, as this is more fitting for email client. In Thunderbird, all WebExtension API can be accessed through the namespace, as with Firefox, but also through the namespace, which is a better fit for Thunderbird. — Thunderbird Developer Documentation: Using WebExtension APIs Could it make sense to introduce a category to include this global, or is it too niche/vendor-specific? This wouldn't reduce the configuration size for downstream projects, as is the only global afaik. So the only gain is that by a user delegating this to , users will know all globals are covered.

https://github.com/sindresorhus/globals/pull/129 was previously rejected, but re-opening because it seems the policy of this repo has changed. There is an existing package, but it has not been touched for years. https://github.com/react-native-community/eslint-plugin-react-native-globals React Native publicly documents their globals in their website sidebar here: https://github.com/facebook/react-native-website/blob/main/website/sidebars.ts#L232 Did not add and because they are currently marked as "Canary and Experimental only". Added because it's listed in their despite missing from the website: https://github.com/facebook/react-native/blob/main/packages/react-native/src/types/globals.d.ts#L13 Added and because their assumes they exist. There are other variables in their that are not publicly documented (e.g. ); not sure what's the policy on adding those. Set the writable flag to for everything. The previous package set for some like but unless I'm missing something, that seems wrong.