Tslint: Roadmap: TSLint -> ESLint

I would be great to have a CLI command that migrates a tslint.json to an eslint.json, mapping equivalent rules and options. Ideally it would remove rules that can be migrated from tslint.json and keep rules that don't have an equivalent yet (or not support the used options), so that the rule can be run idempotently repeatedly over time until tslint.json becomes empty at some point and we can fully rely on ESLint.

Good news.
ESLint guys already started typescript-eslint project to support TS.
They are also looking for help. Here is the statement..

what will writing tslint rules mean after the migration? On tslint I'm happy to write new rules, because it's easy as tslint itself uses typescript and I know type of data while writing rule.

Is there plan to migrate eslint from JS to TS? If not then writing rule will be a bit harder. I hate to say it but if eslint isn't migrated to ts, it'd not be as pleasant to write rules.

My bad, it's not eslint we'll be using, we'll be using typescript-eslint, makes more sense. let me know if I can be of any help.

would it be possible to reference this plan to deprecate from the readme.md in the repo? It seems only certain people know about this plan and isn't common knowledge. Thanks!

@joeyj-msft indeed, added in a395501739bf7f0f166e5b0ccb355c0e9500445a by adidahiya.

It would be nice to have some "recap" of TSLint rules (https://palantir.github.io/tslint/rules/) available in typescript-eslint. Don't know if it should be a "ESLint" flag on palantir or a new list on https://github.com/typescript-eslint/typescript-eslint. But it would help decide if a project is ready to move or not.

@Maximebpro see https://github.com/typescript-eslint/typescript-eslint/blob/master/packages/eslint-plugin/ROADMAP.md :+1:

@JoshuaKGoldberg I am shifting from tslint to typescript-eslint. I was using TSLint to create custom rules for my project. How can I proceed on creating custom rules as same we did in TSLint?

My Project create Javascript as well as Typescript files so I have to create just single rule for them?

@moulikcipherX thanks for asking, great questions!

You can use your TSLint rules within ESLint using typescript-eslint/packages/eslint-plugin-tslint. It wraps a TSLint configuration and lints your code using TSLint.

To write rules in ESLint, see typescript-eslint/packages/eslint-plugin. That README.md has a list of all their supported rules _(the list has gotten pretty big!)_. The ROADMAP.md there has a mapping of existing TSLint rules to the new equivalents.

Thank You @JoshuaKGoldberg.

So I can further use the same methods for creating custom rules for TypeScript same as in TSLint.

Note: I've just updated the original post in this thread with a more concrete roadmap timeline. Scroll to the top of this page to see it.

Er, shouldn't the blog post also be in https://github.com/palantir/tslint/tree/gh-pages/_posts, and linked from https://github.com/palantir/tslint/blob/master/README.md?

@SamB the blog in the gh-pages website is pretty outdated, we haven't been updating it. And the blog post is linked at the top of the README.

@adidahiya @JoshuaKGoldberg
I want to contribute to the typescript-eslint project so where should I start?

@moulikcipherX https://github.com/typescript-eslint/typescript-eslint#how-can-i-help

Will the equivalent transformation from custom tslint rules to custom eslint rules be supported in future typescript-supported-eslint?

What I'm trying to say is having a certain CLI command to convert custom-tslint-rule's JS files to corresponding eslint-compatible linting rules. It will help a lot as to reimplement tslint's rule to eslint will be a really toughing job...

@a20185, yes, that exists now! https://github.com/typescript-eslint/tslint-to-eslint-config

Thanks for creating such a brilliant tool, and I wish you all the best in your future adventures. Speaking of adventures, this has certainly been one, hasn't it?

Anyway, all the best to you,
Will

Seeing as we are coming to the end of 2019 (the year this repo was supposedly being deprecated in), now could be a good time to add the deprecated flag in NPM so new installs are directed at ESLint.

It would be useful, too, to make the readme notice a little more obvious (top level) and link users through to typescript-eslint.

Are you planning on doing this now that almost every common use-case has been covered by ESLint?

I also think and hope that when tslint is deprecated, eslint gets more pressure and the community focuses more on it

The tslint-to-eslint-config helps to convert tslint.json into .eslinerc.js but it cannot
cannot take care of inline tslint:disable:<rule>, also, some rules are not configurated well or not supported by eslint yet.

There are still some edges when migrate from tslint to eslint, whats the benefit to use eslint for typescript files? To get better consistency among the typescript community and javascript community?
If a project only use typescript, without javascript files at all, is there still any benefit after doing the migration?

The tslint-to-eslint-config helps to convert tslint.json into .eslinerc.js but it cannot
cannot take care of inline tslint:disable:<rule>

Indeed: https://github.com/typescript-eslint/tslint-to-eslint-config/issues/136
You're welcome to pitch in to add it if you'd like! There is a work in progress PR at https://github.com/typescript-eslint/tslint-to-eslint-config/pull/246 that could use some help.

There are still some edges when migrate from tslint to eslint, whats the benefit to use eslint for typescript files?

You can see the reasons listed in the blog post mentioned in the top of this thread.

@beenotung

TSLint has always been limited compared to ESLint, there are a whole bunch of rules it never had which ESLint did. Not to mention the plugins and much larger community/support ESLint always had. Additionally, many of us have a nicely configured eslintrc we use everywhere, making any TSLint project an inconsistency that needs fixing (by using a non-obsolete tool).

If there's anything missing from ESLint that TSLint has, its better to raise it so it can be implemented than it is to continue using an obsolete tool.

Thanks for raising more context to eslint, I see the benefit of using eslint.

I actually tried to migrate from tslint to eslint but it seems some edges cannot be fixed easily because eslint does not have the concept of type (hence indentation for generic type is broken).

Regarding tooling support on eslint (especially IDE hints on the configuration file). I wish I can contribute one day but I'm not experienced nor free to work on that currently. (At least it's not in the top of my list because well, tslint still works fine)

It seems the less painful way is to use tslint for typescript files, and eslint for javascript files, so both worlds can enjoy their 'consistency'.

As npm states that TSLint is deprecated and use ESLint instead, I assume the migration is complete.
Shoudn't this issue be closed?

@cdalexndr it's still useful to have this issue open for people to learn about the rationale for the deprecation and to read the latest updates.

Due blog post above is not focused on technical details about typescript-eslint.
TSLint users can read more about on How does typescript-eslint work?

In general, the entire typescript-eslint/README file have all necessary for a transparent transition.

Is there a reason why the package itself is not marked as deprecated on npm? Like e.g. request?

@niklasR version 6.0.0 was marked as deprecated in NPM and then all hell broke loose.

Check out #4919 and #4914 .

We _want_ all hell to break loose though 😛... folks should stop using TSLint.

Looks like we just never explicitly marked the new versions as deprecated; see the version history on https://www.npmjs.com/package/tslint:

I don't have permissions - @adidahiya ?

Oh, strange, I thought the docs here suggested that this command would deprecate all potential future versions which fall into the range:

npm deprecate tslint@^6.0.0 "TSLint has been deprecated in favor of ESLint. Please see https://github.com/palantir/tslint/issues/4534 for more information."

... but I suppose that's not the case. I've gone ahead and deprecated the newer ones.

@adidahiya Thanks, I've opened an issue on the NPM docs here: https://github.com/npm/cli/issues/1165

Should the older versions also be deprecated? Similarly how request does it?

The reason I'm asking is because we're looking at migrating our packages to ESLint, but are using TSLint ^5 quite a lot, and it'd be nice to use our existing process to just scan our (300+) repos for deprecation notices to flag any that need migrating.

Deprecations have always and only ever applied to existing versions; if you want new versions to be deprecated you always have to manually deprecate them after publishing.

Wouldn't be nice for the users to display something very clear about TSLint deprecation on github page https://palantir.github.io/tslint/?

Wouldn't be nice for the users to display something very clear about TSLint deprecation on github page https://palantir.github.io/tslint/?

That is exactly what I have been waiting for! please someone present some clear step-by-step instructions on migrating from tslint to eslint

The TSLint documentation website hasn't been updated in quite a while, but this repo's README is up to date and there's quite a lot of useful information, including a step-by-step guide for migration, in the typescript-eslint README.

Fix for the Error Message
[https://stackoverflow.com/questions/61605380/angular-9-issue-unable-to-run-the-initial-application]
npm install chokidar
npm cache clean --force
npm install -g @angular/cli@latest

Hello Angular team, I am new to angular, please help me with the error I am getting while trying to create a new project.

Thank you.

Hello Angular team, I am new to angular, please help me with the error I am getting while trying to create a new project.

Thank you.

You are at the wrong place
This is palantir and not angular
Please create an issue at https://github.com/angular/angular/issues
Or even better, look up if there is already an issue addressign this problem
Happy to help, see ya

As much as I am dumbfounded by them asking 'here' for Angular help.. I am quite impressed their logo looks like the UK power socket.

@JoshuaKGoldberg Thank you!

The day should also come where you archive/lock this repository.

It shouldn't ever need a code change again. If someone finds a bug now, the solution is to use ESLint rather than dig this long-obsolete project up.

Its nice to see most people are trying to move off it now but the more explicit about abandoning this, the better.

I think ts-lint should no longer be used instead eslint as of Sept 2020

If your project still use ts-lint consider using
checking https://github.com/typescript-eslint/tslint-to-eslint-config

but typescript-eslint doesn't really tell what's wrong https://github.com/typescript-eslint/typescript-eslint/blob/master/docs/getting-started/linting/FAQ.md#why-dont-i-see-typescript-errors-in-my-eslint-output

😢

but typescript-eslint doesn't really tell what's wrong https://github.com/typescript-eslint/typescript-eslint/blob/master/docs/getting-started/linting/FAQ.md#why-dont-i-see-typescript-errors-in-my-eslint-output

😢

I think this is more or less true even of TSLint and why even with TSLint, we also call tsc --noEmit in our linting scripts.

I generated a new angular app with version 8 and it has tslint default shipped with it. I have started using ts config for husky implementation. My question is, is it mandatory to move to typescript-eslint as recommended given the fact that i will be using using Angular 8 in my project for few years to come?

@mayankkalbhor As you've seen, the default with Angular is still to use TSLint. I believe it'll be until Angular 11 or later until all the default configs in Angular CLI are configured for ESLint, see the roadmap: https://angular.io/guide/roadmap#migration-to-eslint.

If you already have something set up you will have to migrate that yourself while there is nothing really forcing you to use ESLint instead of TSLint. It's completely your own choice. If you prefer the features in ESLint or plan to spend time really configuring your rules, perhaps migration is the path for you. If you however are not spending any time configuring your TSLint rules and are happy with them you could continue using them indefinitely. Just don't expect indefinite amounts of bug fixes and no features updates at all.

I believe the default path for Angular developers are to wait for Angular to include migration scripts in some future Angular upgrade, likely from Angular 10 to 11 or 11 to 12.

Anyone is however free to just migrate to ESLint on their own. The only real blocker for you migrating yourself is if you have the time and don't mind losing the features currently not present in equivalent ESLint configurations. Where there have been some linting configurations through Codelyzer previously and we now have an impending replacement here: angular-eslint

As we are reaching the EOL of the software, it would be awesome, if each rule document would have a link to the replacement rule in typescript-eslint documentation, just like typescript-eslint does in reverse.

Does this mean I won't be able to use tslint in my projects after 1st jan 2021? Currently my builds are using tslint. I don't see any command to install tslint on npm website. And it says tslint is deprecated now. Can someone please address my queries?

Thank you.

You can use it, but you wont get any kind of support in any way.
Also no more updates.
So yes, you should move forward to eslint.

As my last checkout, tslint support more types of auto fixing, so I recommend to run 'tslint --fix' before running eslint.

Things may have changed in the meanwhile.

I'll sort it that code ya