Repo: New internal lint rule: don't 'in' check AST nodes #8226
Labels
blocked by another issue
Issues which are not ready because another issue needs to be resolved first
repo maintenance
things to do with maintenance of the repo, and not with code/docs
Suggestion
Sometimes folks will use an
'in'
property check in a rule to narrow the type of a node: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.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 😄
The text was updated successfully, but these errors were encountered: