feat(eslint-plugin): [no-mixed-enums] add rule

[JoshuaKGoldberg]

PR Checklist

• Addresses an existing open issue: fixes Rule proposal: disallow mixed string/numeric enums #2694
• That issue was marked as accepting prs
• Steps in CONTRIBUTING.md were taken

Overview

Adds a no-mixed-enums rule that flags the first member of an enum that mismatches its type compared to previous members. Uses the type checker for this because enum members can sometimes have dynamically computed values:

enum Annoying {
  Gotcha = Math.random()
}

Doesn't ban specifically numeric and/or string member values. Both are extremely common patterns and I don't think there's enough user demand to justify that.

Borrows some documentation from #3891. Thanks 😄

Co-authored-by: @brianconnoly

[nx-cloud]

☁️ Nx Cloud Report

CI is running/has finished running commands for commit 1de4847. As they complete they will appear below. Click to see the status, the terminal output, and the build insights.

📂 See all runs for this branch

---

✅ Successfully ran 47 targets

• Node 18 - nx test eslint-plugin
• Node 14 - nx test eslint-plugin --coverage=false
• nx run-many --target=lint --parallel
• nx run-many --target=typecheck --parallel
• nx run-many --target=build --parallel --exclude website
• nx run-many --target=build --parallel --exclude website
• Node 18 - nx test utils
• Node 18 - nx run-many --target=build --parallel --exclude website
• Node 18 - nx test scope-manager
• Node 18 - nx test typescript-estree
• Node 18 - nx run-many --target=build --parallel --exclude website
• Node 18 - nx run-many --target=build --parallel --exclude website
• nx run-many --target=build --parallel --exclude website
• nx run-many --target=build --parallel --exclude website
• Node 14 - nx test visitor-keys --coverage=false
• Node 18 - nx test visitor-keys
• Node 14 - nx run-many --target=build --parallel --exclude website
• Node 18 - nx run-many --target=build --parallel --exclude website
• Node 18 - nx test parser
• Node 18 - nx run-many --target=build --parallel --exclude website
• Node 18 - nx test type-utils
• Node 18 - nx run-many --target=build --parallel --exclude website
• Node 18 - nx run-many --target=build --parallel --exclude website
• Node 14 - nx test scope-manager --coverage=false
• Node 14 - nx run-many --target=build --parallel --exclude website
• Node 14 - nx test parser --coverage=false
• Node 14 - nx run-many --target=build --parallel --exclude website
• Node 18 - nx test eslint-plugin-internal
• Node 14 - nx test type-utils --coverage=false
• Node 18 - nx run-many --target=build --parallel --exclude website
• Node 14 - nx run-many --target=build --parallel --exclude website
• Node 18 - nx test eslint-plugin-tslint
• Node 18 - nx run-many --target=build --parallel --exclude website
• Node 14 - nx test typescript-estree --coverage=false
• Node 14 - nx run-many --target=build --parallel --exclude website
• Node 14 - nx test eslint-plugin-internal --coverage=false
• Node 14 - nx run-many --target=build --parallel --exclude website
• Node 14 - nx test ast-spec --coverage=false
• Node 14 - nx test utils --coverage=false
• Node 14 - nx run-many --target=build --parallel --exclude website
• Node 14 - nx run-many --target=build --parallel --exclude website
• Node 14 - nx test eslint-plugin-tslint --coverage=false
• Node 14 - nx run-many --target=build --parallel --exclude website
• Node 14 - nx run-many --target=build --parallel --exclude website
• Node 18 - nx test ast-spec
• Node 18 - nx run-many --target=build --parallel --exclude website
• nx run-many --target=build --parallel --exclude website

---

Sent with 💌 from NxCloud.

[typescript-eslint]

Thanks for the PR, @JoshuaKGoldberg!

typescript-eslint is a 100% community driven project, and we are incredibly grateful that you are contributing to that community.

The core maintainers work on this in their personal time, so please understand that it may not be possible for them to review your work immediately.

Thanks again!

---

🙏 Please, if you or your company is finding typescript-eslint valuable, help us sustain the project by sponsoring it transparently on https://opencollective.com/typescript-eslint.

[netlify]

✅ Deploy Preview for typescript-eslint ready!

Name	Link
🔨 Latest commit	1de4847
🔍 Latest deploy log	https://app.netlify.com/sites/typescript-eslint/deploys/63ee7f8c2cb5c300080afa22
😎 Deploy Preview	https://deploy-preview-6102--typescript-eslint.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[codecov]

Codecov Report

Merging #6102 (1de4847) into main (f330e06) will decrease coverage by 0.87%.
The diff coverage is 94.44%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6102      +/-   ##
==========================================
- Coverage   91.52%   90.66%   -0.87%     
==========================================
  Files         371      374       +3     
  Lines       12651    12823     +172     
  Branches     3717     3777      +60     
==========================================
+ Hits        11579    11626      +47     
- Misses        754      853      +99     
- Partials      318      344      +26     

Flag	Coverage Δ
unittest	90.66% <94.44%> (-0.87%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
packages/eslint-plugin/src/rules/no-mixed-enums.ts	94.44% <94.44%> (ø)
packages/typescript-estree/src/convert-comments.ts	57.14% <0.00%> (-42.86%)	⬇️
packages/typescript-estree/src/convert.ts	84.89% <0.00%> (-12.25%)	⬇️
packages/typescript-estree/src/node-utils.ts	83.51% <0.00%> (-7.45%)	⬇️
...escript-estree/src/semantic-or-syntactic-errors.ts	80.00% <0.00%> (-6.67%)	⬇️
...pt-estree/src/parseSettings/createParseSettings.ts	91.30% <0.00%> (-6.20%)	⬇️
...ipt-estree/src/parseSettings/resolveProjectList.ts	91.11% <0.00%> (-4.45%)	⬇️
...ckages/eslint-plugin/src/util/getESLintCoreRule.ts	75.00% <0.00%> (ø)
...nt-plugin/src/rules/no-import-type-side-effects.ts	100.00% <0.00%> (ø)
...-estree/src/parseSettings/getProjectConfigFiles.ts	100.00% <0.00%> (ø)
... and 6 more

[bradzacher]

because enum members can sometimes have dynamically computed values

Note that number enum members are the only ones that are allow to have "complex" computed values:

declare function str(): string;
declare function num(): number;

declare const StRiNgCoNsTrUcToR: { new(): string };
declare const NuMbErCoNsTrUcToR: { new(): number };

enum Foo {
    A = str(),          // invalid
    B = `${'a'}`,       // invalid
    C = str.name,       // invalid
    D = 'a' + 'b',      // valid
    E = new String(''), // invalid
    F = new StRiNgCoNsTrUcToR(), // invalid

    M = num(),          // valid
    N = Number.EPSILON, // valid
    O = 1 + 1,          // valid
    P = new Number(1),  // invalid
    Q = new NuMbErCoNsTrUcToR(), // valid because it's dumb
}

play

This means we don't actually need the typechecker here.
We can simply follow the following logic:

1. if no initialiser, number
2. if initialiser
   1. if string literal or template literal, string
   2. if number literal, number
   3. if binary expression,
      1. if all operands are string literals or template literals, string
      2. else number
   4. if member expression, use type information to get the type
   5. else number

There is just one single caveat to this that I can see - enums built from enums:

enum Foo {
    A = 1,
    B = 'a',
}

enum Bar {
    A = Foo.A,
    B = Foo.B,
}

This is valid TS and creates a mixed enum. But IDK if we really care for this case? Could be a documented edge case that we wait for people to comment on? IDK.

TS even optimises `Bar` at transpile time so that it directly uses the literal values...!

var Foo;
(function (Foo) {
    Foo[Foo["A"] = 1] = "A";
    Foo["B"] = "a";
})(Foo || (Foo = {}));
var Bar;
(function (Bar) {
    Bar[Bar["A"] = 1] = "A";
    Bar["B"] = "a";
})(Bar || (Bar = {}));

[bradzacher]

Looking more, here is another case of valid TS that is dumb, declaration merging:

enum Foo {
    A = 1,
    B = 1,
}
enum Foo {
    C = 'c',
    D = 'd',
}

playground

This will also create a mixed enum. This is much more difficult to handle without types though. I doubt your current code even handles it!

Again, I'd be happy to just document and ignore this case cos this is so so so rare and is really dumb code.

[JoshuaKGoldberg]

enums built from enums

Oh, I've definitely seen this before. 😬 Thinking I'll try to handle it...

[bradzacher]

okay - doing some research on the declaration merging case - I think you can only merge enums in the following cases:

1. if both declarations are in the same file:

   enum Foo { A = 1 }
   enum Foo { B = 2 }
   Foo.A;
   Foo.B;

2. ambiently via module augmentation

   import {AST_NODE_TYPES} from '@typescript-eslint/types';
   
   declare module '@typescript-eslint/types' {
     enum AST_NODE_TYPES {
       WUT = 'WUT',
     }
   }

3. via namespace declaration merging

   namespace Test {
     export enum Bar { A = 1 }
   }
   namespace Test {
     export enum Bar { B = 2 }
   }
   Test.Bar.A;
   Test.Bar.B;

playground

With that in mind - we can probably rework this rule to be faster.

WDYT of the following logic:

TSEnumDeclaration(node) {
  let members = node.members;
  if (
    isWithinTSModuleDecl(node) ||
    enumNameHasTwoDeclarationsInScope(node)
  ) {
    members = members.concat(getMergedMembers(node));
  }
  
  let desiredType: 'string' | 'number';
  for (const member of members) {
    const currentType: 'string' | 'number' = 
      getTypeFromAST(member) ?? getTypeFromTypeInfo(member);

    desiredType ??= currentType;
    if (desiredType !== currentType) {
      report(member);
    }
  }
}

This way we stay fast for cases that we know should be fast (which should be the vast, vast majority of code and cases), and we only dip into the slow type info for the weird edge-cases.

WDYT?

[JoshuaKGoldberg]

Aha you're totally right - thanks for pressing on this! +1. Will do.

It's a pity we can't quite make it to untyped - but yes I do like that this is non-type-checked mostly.

[bradzacher]

overall LGTM!