Chore: Extract some functionality to eslintrc (refs #13481)

[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 autofixing to a rule
[ ] Add a CLI option
[ ] Add something to the core
[x] Other, please explain:

Extracted some functionality into a separate package

What changes did you make? (Give an overview)

I moved several files into the @eslint/eslintrc package and out of this repo. There are files that are specific to the eslintrc configuration format and would have been removed anyway once simple config is implemented. This starts the process of extracting eslintrc from the codebase without introducing any breaking changes.

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

Did I miss any references?

[kaicataldo]

Thanks!

[ljharb]

Heads up that this was a breaking change for sarbbottam/eslint-find-rules#331

That could have been avoided by v7.0.0 using “exports”, or by leaving behind a skeleton file (even one that logged a console warning) that re-exported from the new location. It’d still be great to ship the latter approach in a patch.

[kaicataldo]

Since this isn't part of our public API, I don't think this is something we'll fix. I do think we should start using the exports field to make it clearer to developers what modules are part of the public API (it's defined here, but it would be great to use method prescribed by Node). As a quick note for posterity: in older version of Node that don't have support for exports, main will continue to be used.

[ljharb]

While it's pedantically defensible to say "it's not in our documented api, so it's ok to break people", i would still strongly urge that future changes like this be considered by the far more considerate perspective of "let's not break people". It does not seem painful or difficult for eslint to add a file with something like console.warn('This file is deprecated, and will be removed in v8. Use path/to/new/location instead!') module.exports = require('path/to/new/location';, and to then do a sweep before v8 to remove anything in that category.

[kaicataldo]

This doesn't feel like a fair characterization of how we approach these kinds of changes. I personally wasn't aware that a downstream application was importing an internal module directly, and I'll remind you that we're mostly a small group of overworked volunteers and are doing our best.

[ljharb]

@kaicataldo you're right; i apologize for implying casual breakage was thought about in advance. In general, any removal of a file or method might cause breakage, and I'd hope that could be something kept on folks' mind.

I'd be happy to make a PR to restore the file as I described, if it would be accepted; I don't want to add to yall's quite full plate.

[kaicataldo]

Thanks for that, and I'm sure we could use your expertise as we discuss this change.