I think this also kind of useful, and perhaps it can be auto-fixed in some cases. 👍

we don't like to implement rules that just ban a language feature, because we've found that different people like different things, and unless it's preposterous that you'd use the inverse (like no-ts-ignore), we would want to support the opposite as well.

Happy for something like this to be implemented, but we may want to review it in conjunction with the other enum rules with PRs (#290, #315)

True, I feel there are many similar rules flooded, and would like to have 1 entry point to regulate how enum could be used.

We are using TS as just a pure type checker, so any non-type-system-related syntax/operators will out of our interests. Enum surely have its own syntactical advantages, but because of Babel won't be able to support it properly, then this could be 1 exception here. This rule is helpful to avoid surprise to see why "my const enum code doesn't work".

Will the core no-restricted-syntax work here? I think it should since the enums are language constructs that are traversed-- you would just need to know the proper selector for reporting on them when they are used. (I don't know what that proper selector is, sorry.)

I believe that would work @platinumazure

{
  "rules": {
    "no-restricted-syntax": [
      "error",
      {
        "selector": "TSEnumDeclaration",
        "message": "Don't declare enums"
      }
    ]
  }
}

Tested, the above is the one I am looking for. But I think this rule might be useful if ESLint-TypeScript would ever provide the recommended default setup for Babel users. 🤔

It may be worth noting that you can also disallow either const or non-const enums selectively with no-restricted-syntax rule.

Disallow const enums:

{
  "rules": {
    "no-restricted-syntax": [
      "error",
      {
        "selector": "TSEnumDeclaration[const=true]",
        "message": "Don't declare const enums"
      }
    ]
  }
}

Disallow non-const enums:

{
  "rules": {
    "no-restricted-syntax": [
      "error",
      {
        "selector": "TSEnumDeclaration:not([const=true])",
        "message": "Don't declare non-const enums"
      }
    ]
  }
}

Is there any way to selectively do this so that const enums are allowed for internal package use, but cannot be exported for external consumption?

It's pretty hard / near impossible to detect this.
What does it mean to not be exported? It's a project dependent definition.
Without bundling, every file is technically available to import by a consumer.
With bundling, what is exported depends on how your bundler is configured - i.e. what entry points you define.

A rule like that would have to understand the above, and be able to scan every export from the "external api", and crawl every single type to find any const enums.

I.e. very hard to do, very niche, and outside of the scope of this plugin.