Repository navigation
Rethink this package #82
Description
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?
Activity
sindresorhus commentedon Mar 22, 2016
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 commentedon Mar 24, 2016
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.
add note about not accepting new environments
aotaduy commentedon Apr 12, 2016
Agree with the env plugin approach so in our rules we can check against the rules configured by the eslint user.
nickserv commentedon May 23, 2016
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 commentedon May 24, 2016
@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:
MatthewHerbst commentedon Jan 23, 2018
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,devtoolssindresorhus commentedon Jan 25, 2018
@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 commentedon Jan 25, 2018
@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 commentedon Jan 25, 2018
Yes, I agree it doesn't make sense to manually duplicate them.
soilSpoon commentedon Dec 9, 2020
@sindresorhus Can you pin this issue?
Reference
Pinning an issue to your repository
sindresorhus commentedon Mar 7, 2021
Some initial attempts at generating the globals:
mmkal commentedon Apr 2, 2024
@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'sno-undeferrors 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/Reacttype globals.globals.reactfits pretty neatly into this project I think.nzakas commentedon Apr 2, 2024
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 commentedon Jun 1, 2024
Then I think it's ok to close this. We will consider new environments if there is a lot of demand for it.