Rethink this package

[nzakas]

In the beginning, I think the purpose of this package was to have a single location where the commonly-used globals for JavaScript lived, with the idea that other tools could make use of it.

What we've been seeing, though, is that most requests for new environments come from ESLint users who want an environment for their favorite library. This ends up breaking the feedback cycle where people file issues here instead of with ESLint, meaning the ESLint team doesn't even see them.

Given that ESLint now supports plugins with custom environments, I think we should re-think the goals of this project. Maintaining a list of every library's global objects is something I'm really not interested in doing, and realistically, in the future we'll only care about the ES environment globals because everyone will be using modules, so library-specific globals will be going away.

I'm thinking that maybe this package should be repurposed to just be ES language versions, browser globals, and Node.js globals, and leave the rest to others.

Thoughts?

[sindresorhus]

Agreed.

On the ESLint side, I would encourage people in a blog post to create ESLint plugins for the environments that are going to be removed.

[nzakas]

Yeah, we'll definitely do that before the next breaking release. In the meantime, I'd propose that we stop adding new environments in this package and always direct people to create ESLint plugins with the appropriate environments instead.

[aotaduy]

Agree with the env plugin approach so in our rules we can check against the rules configured by the eslint user.

[nickserv]

Some of the environments in this package (including, for example, prototype) seem to still be for specific libraries and platforms that have extra stuff outside of the ES specs. What is the plan for this? I think it would make sense to have a major version bump which would document what determines an official ES environment, remove all the globals for noncompliant libraries, and extract them into other packages.

[nzakas]

@nicolasmccurdy we haven't started down this path yet, it's going to take a lot of coordination with ESLint to do this in a way that is least disruptive for users. I don't have the time to do that yet.

For your last question/statement, I answered that in the original description:

I'm thinking that maybe this package should be repurposed to just be ES language versions, browser globals, and Node.js globals, and leave the rest to others.

[MatthewHerbst]

Would there be consideration for a breaking change PR that removes all the globals not desired?

Specifically, such a PR would remove: mocha, jasmine, jest, qunit, phantomjs, couch, rhino, nashorn, wsh, jquery, yui, shelljs, prototypejs, meteor, mongo, applescript, atomtest, embertest, protractor, greasemonkey, devtools

[sindresorhus]

@MatthewHerbst Not until there are ESLint plugins for them that covers them and it's coordinated with a major release of ESLint. No rush though. It's not like they're a big burden.

[MatthewHerbst]

@sindresorhus they are and they aren't - I'd like to propose a major change to how the globals in this lib are organized so as to support solving: eslint/eslint#9109

Basically, I want to generate the JSON output using some JS that builds which globals belong in which category. So for example, it would know to fill an "es2017" key with all the globals from the ones before it, that way solving the ESLint config issue without having to continue the duplications of keys in this lib. Imho, each key should be defined once and have a config object listing which categories it belongs to.

[sindresorhus]

Basically, I want to generate the JSON output using some JS that builds which globals belong in which category. So for example, it would know to fill an "es2017" key with all the globals from the ones before it, that way solving the ESLint config issue without having to continue the duplications of keys in this lib. Imho, each key should be defined once and have a config object listing which categories it belongs to.

Yes, I agree it doesn't make sense to manually duplicate them.

[soilSpoon]

@sindresorhus Can you pin this issue?

Reference

Pinning an issue to your repository

[sindresorhus]

Some initial attempts at generating the globals:

• RFC: Dynamically generate globals, drop 3rd party globals #132
• Improve dev tools to update browser variables list. #165

[mmkal]

@sindresorhus @nzakas does this stance still hold now that flat config has shipped, and the docs point users to this package as a recommended way to add globals?

My ulterior motive: I came here because I was surprised to see that react globals aren't included. I didn't want to create an issue/PR for them since this is still linked to in the readme.

React is not "my favourite library", but it's hard to get away from, is the fourth-most used npm package that exists, and it uses (type-level) globals even in modern code. (e.g. const MyComponent = ({children}: {children: React.ReactNode}): JSX.Element => <>{children}</>). eslint's no-undef errors on this kind of thing, and adding globals to a config helps. But IMO this use case is common and valid enough to warrant an exception to the no-more-globals rule?

Note: it is possible to make a plugin even for this use case. But that would require the 66 million people who download this package per week to install another plugin just so they can get JSX/React type globals. globals.react fits pretty neatly into this project I think.

[nzakas]

This issue was opened 8 years ago and I can't remember all the ins and outs of why.

Going forward, ESLint won't be bundling globals, and there is no such things as environments anymore, so I don't think my original concerns apply.

[sindresorhus]

Then I think it's ok to close this. We will consider new environments if there is a lot of demand for it.