RFC: Dynamically generate globals, drop 3rd party globals

[MatthewHerbst]

This is an RFC on the approach being taken, not a fully ready PR. This is to address the discussion in eslint/eslint#9109. At the same time, it takes care of #82 by dropping support of 3rd party globals (I wasn't sure if we consider Node.js to be a 3rd party or not, so kept it for now). We would push this as a major version/breaking change, thus allowing people who still need the 3rd party globals to continue to use them from the older version. As the 3rd parties evolve, they can create new ESLint plugins for them - if they don't exist already, if their globals change.

To minimize the impact of this change, at current the output of the new code is the exact same format as the previous JSON file. This way libraries that use this don't need to change any of their logic. Eventually I think we should output an object config for each global, but that isn't needed at this time.

(If it's a non-starter to remove the 3rd party globals at this point I'll add them back in, but this does seem like a prime opportunity to finally kill them.)

Looking forward to your thoughts, thanks!

---

This changes the globals to be generated dynamically, allowing settings to be applied to each global for easy extensibility into the future. This also allows trivial support for future ESXXXX without having to continue duplicating each global in each year.

[sindresorhus]

I would rather have separate objects for each language version with globals that are unique to that version and then dynamically mix them together.

const es2017globals = ...

[MatthewHerbst]

Thanks for reviewing!

How would you handle knowing when a global has ceased to exist under that approach? (Or are we assuming that once in, a global will always exist, even if deprecated?)

[sindresorhus]

Or are we assuming that once in, a global will always exist, even if deprecated?

Yup

[sindresorhus]

@mysticatea @aladdin-add Does ESLint still intend to drop third-party globals at some point?

[aladdin-add]

╮(╯▽╰)╭ I'm not sure, but I think it requires a RFC to do such a thing. / cc @not-an-aardvark

[not-an-aardvark]

I think eslint/rfcs#9 proposed dropping third-party globals and encouraging users to use the globals package directly. But it's not clear whether that proposal will be accepted, so it's possible we'll continue supporting the existing third-party globals for the forseeable future.

[MatthewHerbst]

so it's possible we'll continue supporting the existing third-party globals for the forseeable future.

@not-an-aardvark Is that because globals supports them, or because you think ESLint should until a decision is made on that within ESLint?

[not-an-aardvark]

Regardless of what globals does, ESLint will probably need to keep supporting the third-party globals for compatibility unless we explicitly decide to drop them. So if this RFC is merged in the short term, we would probably end up working around the changes somehow.

[MatthewHerbst]

I believe that ESLint is the primary consumer of globals (or at least it was when I made this RFC over a year ago). I don't see any issue maintaining the third-party-globals here, especially if ESLint needs them.

[shapkarin]

right, it break the things. Maybe we need to change the script that generates the globals to extract it not from the current env but from the packages itself JSHint and ESLint. I will try to do that with that PR #165 and only for browser env

[sindresorhus]

Closing as this is not moving forward.