Rules_nodejs: Allow disabling tsetse

[pauldraper]

🚀 feature request

Relevant Rules

ts_library

Description

ts_library uses a Bazel-specific linter: https://tsetse.info/

However, these lints are outside of standard TypeScript, so ts_library fails compile some otherwise compliant TS.

Describe the solution you'd like

Add a flag to ts_library to enable/disable tsetse.

Or even better, create a compiler rule or toolchain that could control the presence of compiler plugins like this, with versions for vanilla TypeScript equivalent and the various Google inventions: tsickle, tsetse.

Describe alternatives you've considered

Change the source code to be tsetse compatible.

However, this makes migration of owned code to Bazel even more challenging, and it presents an obstacle in compiling non-Bazel third-party libraries from source.

[alexeagle]

You can do this in your tsconfig.json:

"bazelOptions": {
  "disabledTsetseRules": ["somerule"]
}

Note that Bazel Java similarly enables Error Prone which adds strictness checks to the compiler. We should aim to make this more ergonomic (like can you just turn them all off).
Also I don't see any docs for this so we should add them before closing this issue.

[pauldraper]

Great; this is exactly what I was looking for.

tsetse is fantastic; I just wanted an escape hatch.

[awmichel]

@alexeagle I tried your suggestion, but it had no affect on the tsetse checks.

I found these lines in rules_typescript which suggest the following in my tsconfig.json:

{
  "compilerOptions": {
    "plugins": [
      {
        "name": "@bazel/tsetse",
        "disabledRules": [
          "must-use-promises"
        ]
      }
    ]
  }
}

That syntax works, so this should definitely be left open until the docs are added.

[kylecordes]

BTW, over here we turn the equivalent rule on in tslint (replaced by eslint soon, of course), to ensure all promises are either handled, or explicitly not handled by conspicuously casting to void. I find it odd that this particular rule needs to be turned off - perhaps a large code base with too many intentional promise-with-no-error-handling to sift through?

[awmichel]

@kylecordes That is definitely part of it. I’m working on porting a React Native app to a fully Bazel managed build process and there are over 200 instances of this error.

In most cases they do need to be handled, but 10-20% of cases don’t need to be handled. Instances like analytics/tracking code where success/failure is not a concern of the calling code and when sending some data over the bridge to the native side where no handling of the return code is necessary.

In the cases where no handling of the promise is necessary, it has been problematic to deal with since there isn’t a clear way to ignore the error. ‘//@ts-ignore’ has no effect. I hadn’t considered casting to void though, that’s a good idea.

[kylecordes]

It's particularly easy because it's just 5 characters "void " added at the start of the line, characters with rare reasons to appear anywhere in TX code otherwise.