Repo: enable eslint-plugin/no-property-in-node

[JoshuaKGoldberg]

Suggestion

Sometimes folks will use an 'in' property check in a rule to narrow the type of a node:

declare const node: ts.BinaryExpression | ts.ConditionalExpression;

if ('condition' in node) {
  node
  // ^? const node: ts.ConditionalExpression
}

I've been advising to prefer using less "dynamic" logical gates: existing type predicate functions, direct .kind/.type checks, and/or having different functions for different node selectors.

declare const node: ts.BinaryExpression | ts.ConditionalExpression;

// or:
// if (node.kind === ts.SyntaxKind.ConditionalExpression) {
if (ts.isConditionalExpression(condition)) {
  node
  // ^? const node: ts.ConditionalExpression
}

My reasoning has been that "dynamic" logical gates, beyond being a potential deoptimization in JS perf, are susceptible to the types changing unexpectedly. E.g. a new version of TypeScript might add a new node type to a built-in union that adds a case previously meant to be caught by the rule.

My understanding of in checks is that they're generally reserved for cases where the more "static" ways of checking aren't available.

Shall we encode this as a lint rule?

Similarly positioned to #4796: if eslint-community/eslint-plugin-eslint-plugin#416 is accepted, we can instead enable it in eslint-plugin-eslint-plugin.

Edit: eslint-community/eslint-plugin-eslint-plugin#326, actually 😄

[JoshuaKGoldberg]

Marking as blocked on eslint-community/eslint-plugin-eslint-plugin#326, in that once that exists we'll take it in.

[Josh-Cena]

@JoshuaKGoldberg since eslint-community/eslint-plugin-eslint-plugin#433 exists, we just need to enable it right?

[JoshuaKGoldberg]

Right, yes!