Ideally these refinements should be done in the selector, but then I can't get refined types without doing a lot of ugly assertions.

I'm under the impression we generally try to use objects for the schemas. They're a bit more future-proof and enforce using a property key to explain what the object is for. Only a few rules still have an enum schema.

type: "object" withadditionalProperties: false is preferred.

(are there docs on this anywhere in this project or ESLint core? we should write some somewhere if not...)

String option is preferred when a rule enforces two kinds of styles, and the rule needs to know which side you are on to be functional at all. Object option is used when you are making refinements to the given style. To give a few examples:

• arrow-body-style
• func-style
• consistent-indexed-object-style

I noticed that we tend to use an object containing aprefer property, but IMO that deviates from ESLint core's API design😅 Sometimes ESLint core would haveboth string and object, likefunc-name-matching. When you really look into it, you would understand the differing semantics between string and object.

Yeah the types for these queries can be tricky. More support of us using fancy template literal magicks to parse them (#4065).

Going off the "complex types are from complex code" philosophy: how about splitting this into two queries?VariableDeclarator[init.callee.type='Identifier'][init.type='NewExpression'] could run just the right-hand-side logic.

SearchNodeWithModifiers andTypeParameterWithConstraint for examples of places where we've had to manually adjust node types in the past.

I'm not particularly good at AST selectors, so I always felt a bit cornered when I have to use them...

Also, we simultaneously needlhs andrhs, and there are a few cases (especiallylhs.typeName.name !== rhs.callee.name) where we kind of depend on both for refinement, so I've kept it like this.

I tried, it was ugly refined types like

typeTargetVariableDeclarator=TSESTree.VariableDeclarator&{init:TSESTree.VariableDeclarator["init"]&{type:AST_NODE_TYPES.NewExpression;callee:Extract<TSESTree.VariableDeclarator["init"],{callee:unknown}>["callee"]&{type:AST_NODE_TYPES.Identifier;}};};

Combined with ugly selectors😇 I suggest we don't do it?

this is a nitpick / personal preference

personally I have found that an object for the options is better than a string.
The issue with starting at a string is that if later you want to add options... well you're stuck and you have to support the string and the object form until you remember to breaking-change remove it (if you remember... which we often don't 😓).

Using an object is also nice as it is self-documenting in a way.

i.e.

['error', 'constructor']// vs['error', {prefer: 'constructor'}]

IMO, we should have both—i.e., if we have enhancement options in the future, those should be put third. ESLint follows this convention, e.g.

"arrow-body-style":["error","as-needed",{"requireReturnForObjectLiteral":true}]

The logic is that the rule needs the primary option (do we useconstructor ortype-annotation?) to be functional at all, and enhancement options only tweak existing behaviors, instead of totally flipping it.

See#4924 (comment)

question: do we want to handle namespaced names like
const foo: immutable.Set<string> = new immutable.Set();

Yeah we should... is there a utility function to match potentially nested qualified names?

We don't - I don't think it's something we do all that much!

Let's leave it off for now - we can add it in later.
It's notsuper common to be doing this.

Let's leave it off for now - we can add it in later.
It's notsuper common to be doing this.