Tslint: Rule proposal: use 'const enum' instead of 'enum' when possible.

[LMFinney]

• __TSLint version__: 3.13.0
• __TypeScript version__: 2.0.3
• __Running TSLint via__: CLI

Since const enums are inlined, there is a possible small performance gain when using a const enum instead of an enum. I'd like a rule that would let me know if my enum could be replaced with a const enum to "avoid paying the cost of extra generated code and additional indirection when accessing enum values."

[ajafff]

@LMFinney I gave it a shot: https://www.npmjs.com/package/tslint-consistent-codestyle#prefer-const-enum-wip

This is still work in progress, but early feedback is very appreciated.
Please note the current limitations listed over there.
Also this package only works with tslint@>4 and is developed and tested with typescript 2.1.1

@adidahiya I'd like to develop and test rules in my own repository. If they have come to a certain maturity / quality, I would be glad if some of them could be included in tslint core.

[JoshuaKGoldberg]

OTOH, const enums wreak havoc with Webpack:

• https://github.com/s-panferov/awesome-typescript-loader/issues/137
• https://github.com/Microsoft/TypeScript/issues/16671
• https://github.com/wmonk/create-react-app-typescript/issues/400

If anything, we should have a rule for the other way around: to prefer enums. This leads back to the discussion in a few other rules about being able to generically ban syntax.

[DerGernTod]

OTOH to the previous one: non-const enums cause issues with closure compiler obfuscation:
example:

export enum MASKING_MODE {
    NONE = (1 << 0),
    TEXT = (1 << 1),
    FIELD = (1 << 2),
    INTERACTION = (1 << 3),
    ATTRIBUTE = (1 << 4),
    PASSWORD = (1 << 5)
}

if you use this, you're not able to leverage obfuscation of the enum properties since typescript transpiles it to string constant properties:

define(["require", "exports"], function (require, exports) {
    "use strict";
    Object.defineProperty(exports, "__esModule", { value: true });
    var MASKING_MODE;
    (function (MASKING_MODE) {
        MASKING_MODE[MASKING_MODE["NONE"] = 1] = "NONE";
        MASKING_MODE[MASKING_MODE["TEXT"] = 2] = "TEXT";
        MASKING_MODE[MASKING_MODE["FIELD"] = 4] = "FIELD";
        MASKING_MODE[MASKING_MODE["INTERACTION"] = 8] = "INTERACTION";
        MASKING_MODE[MASKING_MODE["ATTRIBUTE"] = 16] = "ATTRIBUTE";
        MASKING_MODE[MASKING_MODE["PASSWORD"] = 32] = "PASSWORD";
    })(MASKING_MODE = exports.MASKING_MODE || (exports.MASKING_MODE = {}));
});

[JoshuaKGoldberg]

Note: per #4534, this issue will be closed in less than a month if no PR is sent to add the rule. If you _really_ need the rule, custom rules are always an option and can be maintained outside this repo!

[JoshuaKGoldberg]

💀 _It's time!_ 💀

TSLint is being deprecated and no longer accepting pull requests for new rules. See #4534. 😱

If you'd like to see this rule implemented, you have two choices:

• Recommended: Use typescript-eslint to lint your TypeScript code with ESLint ✅
• Legacy: Write it as a custom TSLint rule 🤷‍♂️

👋 It was a pleasure open sourcing with you!

_If you believe this message was posted here in error, please comment so we can re-open the issue!_

[JoshuaKGoldberg]

🤖 Beep boop! 👉 TSLint is deprecated 👈 _(#4534)_ and you should switch to typescript-eslint! 🤖

🔒 This issue is being locked to prevent further unnecessary discussions. Thank you! 👋