Skip to content
This repository has been archived by the owner on Mar 25, 2021. It is now read-only.

TypeScript >=3.8 Support #4914

Closed
rrdelaney opened this issue Feb 25, 2020 · 8 comments · Fixed by #4915
Closed

TypeScript >=3.8 Support #4914

rrdelaney opened this issue Feb 25, 2020 · 8 comments · Fixed by #4915

Comments

@rrdelaney
Copy link
Contributor

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
Copy link
Contributor

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

@JoshuaKGoldberg
Copy link
Contributor

JoshuaKGoldberg commented Feb 25, 2020

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
Copy link
Contributor

@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
Copy link
Contributor

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

@adidahiya
Copy link
Contributor

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

@JoshuaKGoldberg
Copy link
Contributor

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
Copy link
Contributor

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.

@JoshuaKGoldberg
Copy link
Contributor

🤖 Beep boop! 👉 TSLint is deprecated 👈 and you should switch to typescript-eslint! 🤖

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

@palantir palantir locked and limited conversation to collaborators Sep 15, 2020
@JoshuaKGoldberg JoshuaKGoldberg unpinned this issue Sep 15, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants