TypeScript >=3.8 Support

[rrdelaney]

Hi! 👋

TSLint no longer builds using TypeScript 3.8, and we'd like to fix the source code up to at least be able to build TSLint, without adding new features. I talked with @JoshuaKGoldberg a bit about this last Friday, and we seemed to think this was a feasible idea 😄This issue is mostly just for tracking our effort, and fielding if TSLint would be open to PR's before we begin implementation.

[Shinigami92]

TSLint is deprecated, https://github.com/typescript-eslint/typescript-eslint should be used as a successor

[JoshuaKGoldberg]

Indeed, TSLint is deprecated, but we would want to still be able to build source code in the case of needing to release a security fix -- as explicitly mentioned in #4534.

@rrdelaney we would definitely welcome PRs to fix the source. #4888 is probably a good start. You mentioned offline that the AST changes in TS 3.8 are also bad for TSLint. It'd be nice to have one issue for each group of source building breakage, though I understand it can be hard to group them without a deep investigation.

Thanks for offering to implement! 😄

[JoshuaKGoldberg]

@adidahiya what are your thoughts on releasing a patch version that fixes TS 3.8 crashes, and in general, releasing patch versions for breaking TypeScript changes?

It's my understanding that some larger framework users -e.g. Angular- don't yet have a fully supported option to switch to typescript-eslint (Angular reference: angular/angular-cli#13732). Which means they're stuck with us for now.

I'd be in favor of expanding the schedule in #4534 to include security fixes and fixes for crashes introduced by breaking TypeScript changes.

[Shinigami92]

Why invest time in a dead project instead of invest time to help projects like Angular finish the migration?

[adidahiya]

@JoshuaKGoldberg I'm certainly open to it if it's not too much work... supporting 3.8 sounds like a good idea

[JoshuaKGoldberg]

Good question @Shinigami92! A couple of main reasons:

• It'd be very little work to release a new patch version of TSLint with the fixes from this issue. Helping Angular finish the migration is quite a lot of work.
• Even when, say, a new version of Angular completely migrates to ESLint, many users will still be stuck on older versions that rely on TSLint.

For what it's worth, this isn't an either-or choice. We have been investing in helping kill TSLint quite a bit, such as with tslint-to-eslint-config and migrating TSLint rules to typescript-eslint.

[JoshuaKGoldberg]

Super, thanks Adidahiya! I'll place an additive edit in #4534 to mention the policy change and work with @rrdelaney on getting these changes in.