feat: Move all and recommended configs into package.

[nzakas]

Prerequisites checklist

• I have read the contributing guidelines.

What is the purpose of this pull request? (put an "X" next to an item)

[ ] Documentation update
[ ] Bug fix (template)
[ ] New rule (template)
[ ] Changes an existing rule (template)
[ ] Add autofix to a rule
[ ] Add a CLI option
[x] Add something to the core
[ ] Other, please explain:

What changes did you make? (Give an overview)

Relocates the "eslint:all" and "eslint:recommended" configs into the @eslint/js package so they can be referenced from there instead of as strings. I needed to change the "eslint:all" file to be autogenerated at build time rather than from run time because it won't be able to reference the full rule list at run time. (The rules are outside of the package.)

In order to do this, I had to do an initial publish of @eslint/js. I also added a Jenkins job to make releasing this package easy.

Additionally, whenever a file in the lib/rules directory is lint-staged will regenerate eslint-all.js so that we are automatically updating that configuration. We will still have to manually release @eslint/js in the short term if there are any changes.

Fixes #16537

Is there anything you'd like reviewers to focus on?

I added a deprecation notice for using "eslint:recommended" and "eslint:all" as strings inside of flat config to let people know they should switch to @eslint/js. Because people are starting to use flat config, I don't think we want to break this usage. Currently, this results in deprecation notices even when using FlatCompat because we just pass through the strings.

Does it make sense to update @eslint/eslintrc to use @eslint/js directly as well? Or, should we force people to pass in their own reference to @eslint/js in the FlatCompat constructor?

[netlify]

✅ Deploy Preview for docs-eslint canceled.

Name	Link
🔨 Latest commit	f8e0b9c
🔍 Latest deploy log	https://app.netlify.com/sites/docs-eslint/deploys/63e6bcde638cd700072046e8

[nzakas]

I still need some guidance on this bit:

I added a deprecation notice for using "eslint:recommended" and "eslint:all" as strings inside of flat config to let people know they should switch to @eslint/js. Because people are starting to use flat config, I don't think we want to break this usage. Currently, this results in deprecation notices even when using FlatCompat because we just pass through the strings.

Does it make sense to update @eslint/eslintrc to use @eslint/js directly as well? Or, should we force people to pass in their own reference to @eslint/js in the FlatCompat constructor?

[nzakas]

@mdjermanovic @btmills I'm blocked on answering that last question. Can you please take a look?

[mdjermanovic]

Does it make sense to update @eslint/eslintrc to use @eslint/js directly as well? Or, should we force people to pass in their own reference to @eslint/js in the FlatCompat constructor?

I think users should pass in their own references because the sets of all and recommended rules depend on the version of ESLint they're using.

[nzakas]

That was my thinking, as well. I'll make that change.

[mdjermanovic]

We will still have to manually release @eslint/js in the short term if there are any changes.

How will we manage versions of the @eslint/js package? The current version is 8.33.0 and the configs contain rules available in ESLint v8.33.0.

Then, for example, we add a new rule in ESLint v8.40.0, so we should also update the eslint:all configuration in @eslint/js and release a new version of this package as well. Will we bump the version to 8.40.0 to match ESLint's version?

[ljharb]

Please don't do lockstep versioning, babel already learned from this mistake :-)

[nzakas]

I think in the short term it will have to be lockstep releases or else it will be confusing to understand what eslint:all actually means.

The goal is to move all the JS-specific rules, etc. into @eslint/js, so eventually there will be no need for lockstep releases. Temporary pain as we get the infrastructure into the state we want it.

[nzakas]

eslintrc PR: eslint/eslintrc#103

[mdjermanovic]

LGTM, thanks!

Not merging until eslint/eslintrc#103 is verified.

[mdjermanovic]

I think in the short term it will have to be lockstep releases or else it will be confusing to understand what eslint:all actually means.

Does this mean that we'll release @eslint/js every time we release eslint, even if there are no changes in @eslint/js, just to bump the latest version to match eslint version?

[nzakas]

Does this mean that we'll release @eslint/js every time we release eslint, even if there are no changes in @eslint/js, just to bump the latest version to match eslint version?

That's what I was thinking. My main concern is making sure people understand what eslint:all will actually contain. If eslint and @eslint/js have the same version number, then it's easy to tell at a glance that they work together. If we let the two package versions diverge, that relationship gets blurry and could cause confusion.

I'm not super attached to that. If folks think letting the version numbers diverge makes more sense, that's fine with me. I'm willing to bet eslint:all users are a tiny minority of users and that this decision won't affect many.

As I mentioned, eventually the two package versions will diverge, it just seemed like a good idea to hold that off until @eslint/js was completely self-contained.

[mdjermanovic]

That's what I was thinking. My main concern is making sure people understand what eslint:all will actually contain. If eslint and @eslint/js have the same version number, then it's easy to tell at a glance that they work together. If we let the two package versions diverge, that relationship gets blurry and could cause confusion.

Makes sense to me. 👍

While at this, the next version of eslint will be 8.35.0. So, we'll need @eslint/js v8.35.0. But the current version of @eslint/js is v8.33.0. Shall we release both v8.34.0 and v8.35.0 of @eslint/js this week?

[mdjermanovic]

eslint/eslintrc#103 has already been merged, so I'm going to merge this too.