Investigating ESLint migration

[43081j]

Hello 👋

Recently, out of interest, I made a branch of dtslint which drops tslint entirely and uses ESLint instead.

TSLint has been obsolete for a very long time, and deprecated for quite some time too. It would be good to move towards removing it IMO, is that something you're interested in?

I'm happy to continue my branch if that's the case, but it would be very nice to have some help converting the individual rules as there are many and I haven't touched this repo before.

Couple of notes from what I've found so far:

• dts-critic returns a diagnostic which has a position of {start, length} which is aligned with TSLint but not ESLint. In ESLint we need a {column, line} or a Node
• Rules can be converted easily if you understand their logic already, this is where I am slow since I have to first understand each rule's intention and what it does
• We used to interact with the typescript api directly, but it seems this might go away as you can simply rely on ESLint to have already parsed/processed the AST instead
• For those rules that need type information, if any, we can use typescript-eslint's additional types/helpers

If you're interested in seeing my branch, i could make a draft PR which doesn't yet build and leave comments where I'm unsure what to do (usually vague types that were previously any or inferred).

[orta]

Hi! Sorry it took a while for us to respond.

We've also been thinking about this off and on, and are definitely open to getting it working and replacing tslint! I've pushed a new branch which we can work towards: https://github.com/microsoft/dtslint/tree/eslint_base

[43081j]

do you want me to open a draft PR against that? its been a while so ill catch it up from master too while im in there.

then we can decide if the stuff i already did is worth using as a starting point or not

[orta]

Yeah, that'd be great!

[JoshuaKGoldberg]

👋 is anything happening here? I'd be interested in pitching in!

[43081j]

@JoshuaKGoldberg it is being tracked in #325 by @sandersn , although he's presumably been preoccupied with other stuff recently. But reviewing that pr would be a good start I think

[43081j]

#325 is stale as sanders doesn't currently have the time to push ahead with it, so any takers for opening a new PR would be great.

some feedback from me:

• we should probably see if there's a sensible way to migrate a rule at a time, one PR per rule
• similarly investigate how we can run both linters alongside each other when necessary
• IMO we should start with little or no eslint plugins to avoid pulling in bloat, ideally this repo can ultimately behave like an eslint plugin in the end

[JoshuaKGoldberg]

Yeah I'm planning on looking at this within the next week or so. My rough thoughts are that it would be cleanest long term to promote eslint-plugin-expect-type, so that folks don't need a separate linting tool other than ESLint.

From the perspective of DefinitelyTyped it would likely be very difficult to immediately switch from ESLint to TSLint given the sheer scale of the codebase and how many equivalent rules have subtle differences between the two linters. My first guess for a strategy would be something like:

1. Add ESLint + typescript-eslint for explicitly just the expect-type ruleset, removing the need for most or all of dtslint [edit: see below comment]
   • Use typescript-eslint's TSLint runner to run TSLint inside ESLint
2. Switch over rules one by one from TSLint to ESLint
3. Remove TSLint altogether

...but that's just a rough guess that should be validated 😄

[43081j]

keep in mind dtslint has plenty of useful rules beyond type assertions. that is actually only one rule, a small amount of the source of dtslint.

if there's enough complexity in that one rule to justify pulling in third party libs, fair enough.

the rest can mostly be converted fairly easily (but time consuming). so it would be super nice if we could have them running alongside each other which i think is what you're saying. so we can migrate a rule at a time, leaving the rest to continue using tslint.

i also already have a branch with some of those rules converted but none of the surrounding architecture updated to call them properly. so let me know if you want any of that in your efforts

[JoshuaKGoldberg]

I've reached out to @ibezkrovnyi to talk about eslint-plugin-expect-type. Looking through https://github.com/microsoft/dtslint/tree/76886d9/docs, indeed, there are quite a few rules that don't make sense under an "expect type" umbrella. I wonder if changing to a name like eslint-plugin-types is a reasonable future?

[sandersn]

I don't know the eslint naming scheme, but the rules are really style rules for Definitely Typed. I'd say that (at least) a few of them don't make sense outside that context, like the lint rules about when to use declare vs export in a d.ts file. Does eslint-plugin-definitely-typed make sense? That's just a guess.

[JoshuaKGoldberg]

Maybe two packages then, eslint-plugin-types and eslint-plugin-definitelytyped?

My main goal here is extracting the parts of dtslint that are broadly applicable into a standard ESLint plugin. My secondary goal is making dtslint use a typical ESLint plugin architecture so it can be made portable.

[43081j]

Yeah I mean there's a good amount of purely dt-specific rules that should continue to live in this repo (even if this repo becomes an eslint plugin). But it's true a couple of them could be useful to other people, through even then someone could just use this plugin (eslint-plugin-dts for example, we could call it).

I've also converted a fair few of the rules already to eslint rules. if someone gets time to convert the architecture in general I could easily pr them in