Add ESLint configs to @babel/eslint-plugin + @babel/eslint-plugin-development

[swansontec]

Q	A
Fixed Issues?	#10752 (partially)
Patch: Bug Fix?	Yes
Major: Breaking Change?	No
Minor: New Feature?	Yes
Tests Added + Pass?	N/A
Documentation PR Link
Any Dependency Changes?	No
License	MIT

These commits add recommended ESLint configs to the two plugins. With this, users can enable the plugins and activate their rules in a single line, like so:

{
  "extends": ["plugin:@babel/eslint-plugin/recommended"]
}

While doing this work, I noticed that the documentation for @babel/eslint-plugin had some typos, so I fixed those.

I also noticed that @babel/eslint-plugin exports a rulesConfig, which was removed in ESLint 2. I left that in with a comment, since removing it would be a breaking change, but then again this whole package is being renamed, so maybe now is a good time to remove it.

[swansontec]

Hrm, the test failure seems unrelated to these changes. I'll try a rebase once master is clean.

[kaicataldo]

Thanks for the PR. For some context, all of the ESLint-related packages are in the process of being ported over to the monorepo and being updated so that we can publish them under the new name in a hopefully less broken and much easier to maintain state. As a result, there’s a good chance a lot of this will be undone as we figure out what we want this plugin to actually do going forward. I’m hoping to remove all the deprecated rules, audit the remaining ones to see if they’re still necessary, and try to come up with a better strategy for discovery of where core rules break with experimental syntax. The readme was intentionally left in an incomplete state because I was assuming we’d have to rewrite it all anyway 🙂

My end goal is to have a way to configure Babel-related rules and the parser with a single config, but I don’t think we should add the recommended config until after we do the other work and can take stock of what we want this to actually look like.

[swansontec]

Thanks for the quick reply!

Thanks for the PR. For some context, all of the ESLint-related packages are in the process of being ported over to the monorepo and being updated so that we can publish them under the new name in a hopefully less broken and much easier to maintain state.

I noticed that this work was ongoing, and tried to contribute along those lines.

I’m hoping to remove all the deprecated rules, audit the remaining ones to see if they’re still necessary,

I can update this PR to do that if you like.

and try to come up with a better strategy for discovery of where core rules break with experimental syntax.

Yeah, that's a tricky one. You need to exercise the ESLint core rules on some codebase that includes the experimental features, but you also need to know what the "correct" outcome for those rules should be. If TC39 allows dangling commas in some new location, for example, a rule like no-comma-dangle wouldn't actually realize it needs to check there. It's not clear how to automate this, besides the "million monkeys" approach of just waiting for bug reports to come in.

The readme was intentionally left in an incomplete state because I was assuming we’d have to rewrite it all anyway 🙂

It's not that bad, actually, especially now with the fixes.

My end goal is to have a way to configure Babel-related rules and the parser with a single config, but I don’t think we should add the recommended config until after we do the other work and can take stock of what we want this to actually look like.

The config I added does this, but it sounds like the main question at this point is what the final rule-set should be.

[kaicataldo]

I’m just starting in on this process and need to spend some time investigating before I come up with an actual proposal.

Just so you’re aware, my current priorities are:

1. Fix bugs in@babel/eslint-parser and finalize the API.
2. Investigate the current status of @babel/eslint-plugin and do the work I discussed above.
3. Audit and make sure @babel/eslint-plug-in-development is in a good place.

My inclination right now is to hold off on merging this and work on the parser first. Once we have the parser in a good place, we’ll be able to evaluate what the plugin should do.

Would love to have your help along the way if you’re interested! I’ll see if I can make a Slack channel for this work later today :)