Migrate from tslint to eslint

[eps1lon]

Looking for replacements of the following tslint rules:

• deprecation
• dtslint/no-relative-import-from-test

[tiuweehan]

Hi, I would like to look into this issue if it is available.

[joshwooding]

@tiuweehan Due to the “good to take” label I would say it’s available and feel free to investigate it.

[eps1lon]

An alternative to https://github.com/ibezkrovnyi/eslint-plugin-expect-type#readme might be https://github.com/4Catalyzer/eslint-plugin-ts-expect

[eps1lon]

Hopefully microsoft/TypeScript#36014 gets released. Then we could already switch from tslint to tsc. Should also help with overzealous IDEs that report a many issues in the repo (that are expected).

$ExpectType is a bit harder though.

[ExE-Boss]

For $ExpectType, I just use:

declare function expectType<T>(value: T): T;

from tsd.

[eps1lon]

With TypeScript 3.9 we'll be able to replace $ExpectError with @ts-expect-error. As soon as 3.9 is stable we can merge master...eps1lon:chore/remove-expect-error. Resolved in #21308

For $ExpectType we have to do a bit more research since I suspect that most solutions that test for assignability do not consider any. Done in #21309

There are some other rules where it's not obvious that eslint-typescript implements them:

• deprecation
• dtslint/no-relative-import-from-test

[dragos199993]

What is the status of this issue? I would like to start on this.
Thanks

[eps1lon]

What is the status of this issue? I would like to start on this.
Thanks

We're looking for a replacement of the following tslint rules:

• deprecation
• dtslint/no-relative-import-from-test

[jenniferabowd]

Hi, I'm happy to pick this up, but I see that there is already EsLint in this project. The contributing guidelines also talks about EsLint. I found two packages to fix the above issues, https://github.com/gund/eslint-plugin-deprecation and https://github.com/fr0stf0x/eslint-plugin-absolute-imports. What are the steps left that are needed to fully transition over to EsLint or is this issue outdated?

[jmetev1]

I played around with this and have a few questions:

Current situation from what I read above:

We use tslint deprecation rule to warn us when using deprecated things. In mui base package, running yarn typescript will run tslint which will alert us to problems.

What i experience:

I wanted to make sure I understood what deprecation rule was doing. So i tried to trigger it in mui-base. but the typescript command glob pattern in mui-base is overriding what is in muibase/tsconfig.json and only checking spec and d.ts files i believe. So I made a pr to change that and now a ton of stuff fails tslint. In addition the deprecation rule itself seems to be throwing an error. TypeError: message.trim is not a function at Function.Rule.FAILURE_STRING

Outcome:

So now I'm not sure what was intended or where this should go from here. Same thing about what files are tslinted goes for some other packages like mui-joy.
Hope this was helpful and i actually understand what's going on!
@eps1lon

[jmetev1]

Also I tried out https://github.com/gund/eslint-plugin-deprecation which jennifer mentioned and it works. But boy is it slow. I guess eslint is caching so it's only slow the first time. But I limited linting to one package, like mui-joy, and it took over 50 seconds.