typescript-eslint Sharing logic between rules
Two copies of tricky type logic drift apart: one gets a bug fix, the other doesn't, and the second bug surfaces months later.
Copied rule logic goes into a util
The target is a non-trivial helper function duplicated between rules — not duplication in general. Move it to a shared file and have both rules import it. That case is a change request, not a nit.
Signals:
- it appears in the diff and also, near-verbatim, in another rule under
packages/eslint-plugin/src/rules; - it carries the same explanatory comments as its twin;
- it answers a question any rule might ask — "does this class extend a specified base?", "is this expression higher precedence than
await?"
Consider placing these, in order of scope: packages/eslint-plugin/src/util for rule helpers, packages/type-utils/src for anything about ts.Type, packages/utils/src for what plugin consumers need too.
This does not extend to repeated boilerplate outside rule logic. Identical blocks across package entry points, near-identical CI jobs, parallel config files, and repeated test scaffolding are normal here and are not raised in review. Flag duplication only when both copies are logic that could drift apart into a bug.
When copies differ, parameterize
Two helpers that are almost the same still deduplicate — the difference becomes an argument.
Two rules each answered "is this type, or any of its base types, allowed?", one matching a legacy name list and one a TypeOrValueSpecifier. The shared version takes the matcher:
export function matchesTypeOrBaseType(
services: ParserServicesWithTypeInformation,
matcher: (type: ts.Type) => boolean,
type: ts.Type,
seen = new Set<ts.Type>(),
): boolean {
// no-base-to-string.ts
matchesTypeOrBaseType(
services,
type => ignoredTypeNames.includes(getTypeName(checker, type)),
type,
);
// restrict-template-expressions.ts
matchesTypeOrBaseType(
services,
type => typeMatchesSomeSpecifier(type, allow, program),
type,
);
Two functions only ever called as a pair are one function, not two exports.
Reach for the util that already exists
| Question | Use | Not |
|---|---|---|
| Is this type from the default library? | isSymbolFromDefaultLibrary, program.isSourceFileDefaultLibrary |
a filename check, which ./src/gotcha.lib.d.ts defeats |
| Does this type or value match a user-configured target? | TypeOrValueSpecifier |
comparing names, which matches coincidentally |
| What is this computed key's value? | getStaticValue, getStaticMemberAccessValue |
handling only literals |
| Is this a definition file? | the same expression TypeScript itself uses | an approximation |
A new util needs its call sites
A helper added with no callers is untested and unproven. Find the existing code it replaces and convert it in the same PR — at minimum the straightforward cases.
- if (functionTSNode.type) {
- const returnType = checker.getTypeFromTypeNode(functionTSNode.type);
+ if (functionNode.returnType) {
+ const returnType = services.getTypeFromTypeNode(
+ functionNode.returnType.typeAnnotation,
+ );
Generalize what is publicly exported
A util exported from @typescript-eslint/type-utils or @typescript-eslint/utils is public API, so it must handle more than the rule that prompted it. A helper covering only Identifier and JSXIdentifier is fine while internal; once exported it needs private properties, computed keys, and the rest — or a narrower parameter type so callers cannot pass what it does not handle.
Exceptions
- Don't deduplicate a one-liner. Extract logic long enough to hold a bug.
- Small, single-purpose fixtures and test helpers stay local.
- Don't churn unrelated rules. If converting every call site would balloon the diff, convert the straightforward ones and note the rest for a followup.
- A near-duplicate needing three flags to unify is two functions.