Make ast-utils (or parts of it) extensible for new operators?

[platinumazure]

Inspired by #10399.

I think we need to start considering other ways to make ESLint (especially ast-utils) extensible, without taking on a large maintenance burden.

To solve #10399 in particular, we would need to make ast-utils (and code-path-analysis, but I'd like to focus on ast-utils in this issue) more extensible somehow.

We could potentially do so at a few different levels:

1. Very narrow: Expose a way to override just operator precedence, and have ast-utils use that.
2. Very broad: Create an ast-utils interface and allow consumers to create full implementations.
3. Somewhere in the middle (?)

Personally, I could see some value in implementing some sort of Operators interface, which would contain precedence, arity, postfix/prefix, short-circuit, and other information, and let that be extensible by custom parsers and injectable into ast-utils and code-path-analysis. But I don't know if that's the best approach.

[not-an-aardvark]

I like the general idea of allowing parsers to specify more of the behavior of custom syntax that's currently handled in ast-utils. I'm not sure we should expose the entire ast-utils interface (since it's quite large, and it's currently a bit of a dumping ground for any helper functions that need to be shared between rules). But it seems like it could be useful to stabilize/provide an interface for a subset of that behavior.

I'm not sure how easy it would be to have a general interface for operator behavior. For example, the new operator in JavaScript has different precedence depending on whether the callee uses parentheses for arguments. This difference currently isn't handled by ast-utils -- instead there is special logic for it in no-extra-parens.

[mysticatea]

Since the ast-utils is a detail of implementation, so I don't think we should export it. I think we should focus on the language features. Now, the custom parser cannot control some language features:

• the operator precedence of new operators.
• the code path of new syntaxes.

There may be others.

It will be nice if the custom parsers can control those.

[aladdin-add]

closing, as it seems have been addressed by #10476 .