Rule proposal: Const enum

[sindresorhus]

The user would be able to configure this rule to either enforce always using const enum or always disallow it.

Relevant TSLint issue: palantir/tslint#1798

[j-f1]

This would be valuable since Babel doesn’t support const enum.

[mohsen1]

My take on enums:

in a lot of cases const enums can be replaced with literal types. actual enums are useful only if they take advantage of declaration merging otherwise they should be const enum which can be replaced with literal types.

[bradzacher]

enums are usually nicer than literals for two reasons:

1. You can use the TS language service to refactor rename them across your workspace.
2. If you're not basing the enum of an external API, you can make them opaque (i.e. don't provide a value) - meaning people can't accidentally use literals in comparisons, etc
   • using literals is really hard to refactor, and can cause bugs if you're not careful

Example:

enum StrFoo {
    a = 'a'
}
const y: StrFoo = StrFoo.a;
if (y === 'a') {  // is compile-time safe, but hard to refactor
    
}

enum NumFoo {
    a = 1
}
const z: NumFoo = NumFoo.a;
if (z === 1) { // is compile-time safe, but hard to refactor
    
}

enum Foo {
    a
}
const x: Foo = Foo.a;
if (x === 'a') { // is NOT compile-time safe
    
}

repl

If you refactor enum names or adjust the values, then you can very easily create subtle bugs that are type safe

 enum NumFoo {
-   a = 1
+   a = 0
+   b = 1
 }
 const y: NumFoo = NumFoo.a;
 if (y === 1) {  // this check is compile-time correct, but the logic is now broken because we've changed the enum values.
     
 }

There's a big reason that the flow team is scrambling to add enums to their language - because using string literals and string unions is really, really clunky and causes you to have to write a lot of unnecessary code.

[mohsen1]

Never considered refactoring. That's a very good point! 👏🏽

[mohsen1]

I'm working on a rule for this. I call it enum-style with following options:

Default config:

{
    "enum-style": ["error", "no-const"]
}

• no-const Do not allow const enum
• no-enum Do not allow any type of enum
• const Only const enum is allowed

[mysticatea]

The rule name sounds good.
But I'd like to suggest the option names are not negated. The option name should show the style people use, rather than it implicitly shows style by disallowing the other side.

[mohsen1]

How about this:

• enum: Only non-const enum is allowed
  • This option name doesn't feel clear to me. Maybe ban-const?
• ban Do not allow any type of enum
• const Only const enum is allowed

[mysticatea]

How about an option object:

{
  "const": "always" | "never" | "any",
  // "memberType": "number" | "string" | "any"
}

I'm not sure if this rule disallows enum syntax itself. Do other options disallow the union type of literal types? If no, it's not symmetry.

[mysticatea]

I'm leaning towards focus on only const.

{
    "enum-const-style": ["error", "always" | "never"],
    // "enum-member-style":  ["error", "number" | "string"],
    // "enum-syntax-style":  ["error", "enum" | "literal-union"],
}

This should be the intention of this issue.

[mohsen1]

bringing const to name makes the "ban" option a bit weird. I agree that other options I mentioned in the PR belong to their own rules.