Discuss tslint rules

During development, tslint can be a great productivity killer. Especially when long running builds are stopped because of questionable rules. My overall experience is that for every 1 good hint, there are about 10 annoying, useless build breaks.

To ensure the tool is helping is more than it is blocking, I’d like to share rules I like and rules I don’t like.

Good ones:

• triple-equals (e.g. iov-core/packages/iov-keycontrol/src/keyring-entries/slip10.ts[117, 21]: != should be !==
• typedef (shows missing types, e.g. if a function does not specify return types)
• prefer-const (shows when const would be possible)

Medium ones:

• ordered-imports (e.g. iov-core/packages/iov-keycontrol/src/keyring-entries/slip10.ts[7, 3]: Named imports must be alphabetized.): sometimes annoying, especially when order changes because of renamings. But overall good to have them for aesthetics. Would be good if the formatter could sort the makes for us but prettier does not want to: https://github.com/prettier/prettier/issues/949. Maybe it would be worth to test the tslint fixer for this
• no-empty: well, if I write and empty block it is supposed to be empty. However, don’t have a good example right now
• comment-format: for quickly commenting out a line like “//a++;” this breaks the build because a trailing space is missing. But probably has some value for the resulting code style
• readonly-keyword/no-object-mutation/readonly-array: helped a bit from time to time but let’s non-immutable members appear as a bad thing, which it isn’t.

Annoying ones:

• no-empty-interface: if write and empty interface it is supposed to be empty, e.g. export interface NewBlockHeaderEvent extends Header {}
• no-let: This is needed for every conditional assignment, e.g.

    // tslint:disable-next-line:no-let
    let pubkeyBytes: PublicKeyBytes;
    switch (this.curve) {
      case Slip10Curve.Ed25519:
        {
          const keypair = await Ed25519.makeKeypair(derivationResult.privkey);
          pubkeyBytes = keypair.pubkey as PublicKeyBytes;
        }
        break;
      case Slip10Curve.Secp256k1:
        {
          const keypair = await Secp256k1.makeKeypair(derivationResult.privkey);
          pubkeyBytes = keypair.pubkey as PublicKeyBytes;
        }
        break;
      default:
        throw new Error("Unknown curve");
    }
  

  and with prefer-const in place, you already get an error when let is not needed
• no-console: console calls are often the easiest way to debug some data. Writing “// tslint:disable-next-line:no-console” without typos and without forgetting the trailing space often takes as much time as 2 build and update iterations. I think we should kick out console calls during code review for production code

If there are no string opinions against it, I’d like to disable no-console and no-let by default and try to get auto-fixing running for ordered-imports.

[webmaster128]

Let me remove the inline-exceptions for the now deactivated no-let and no-empty-interfaces and than close

[ethanfrey]

@webmaster128 does #313 close this? or anything else to add?