Bryan Mishkin

I'm open to it. Should this be an issue in https://github.com/bmish/eslint-doc-generator?

I believe it's a breaking change as anyone with flat rule tests that use `languageOptions` will suddenly have a new ordering of this property enforced.

I'm open to accepting rules targeted at TypeScript rules/syntax, including this one. I previously added general [compatibility](https://github.com/eslint-community/eslint-plugin-eslint-plugin/pull/197) with TypeScript rules in [v4](https://github.com/eslint-community/eslint-plugin-eslint-plugin/releases/tag/v4.0.0). Any new rule targeted at TypeScript rules should...

@MichaelDeBoey how will the automatic releases work? When will they happen? And what if we want to do a single release with multiple changes?

Should we add the github badge so people know things will be released automatically? https://github.com/semantic-release/semantic-release#badge

Should we get rid of `release-it` at this point to avoid having multiple systems in place for releasing? Added here: https://github.com/eslint-community/eslint-plugin-eslint-plugin/pull/131

Is this compatible with the conventional commits we currently use? https://github.com/eslint-community/eslint-plugin-eslint-plugin/pull/221

I agree that it's safer and clearer to check the node type instead of whether the node has a particular property. And it sounds like the `in` operator is the...

Adding the dependency sounds fine. Is there any way we could avoid adding additional configs? I'm generally not a big fan of adding configs as most people just use `recommended`...

I do think it's a good point that having automatic rule logic based on environmental factors is not necessarily a great practice and can theoretically cause confusion or reduce the...