:sparkles: Monorepo for all the tooling which enables ESLint to support TypeScript
Monorepo for all the tooling which enables ESLint to support TypeScript
typescript-eslintwork and why do you have multiple packages?
The documentation below will give you an overview of what this project is, why it exists and how it works at a high level.
It is crucial that you are familiar with these concepts before reporting issues, so it is a good idea to read them before raising issues.
As covered by the previous section, both ESLint and TypeScript rely on turning your source code into a data format called an AST in order to do their jobs.
However, it turns out that ESLint and TypeScript use different ASTs to each other.
The reason for this difference is not so interesting or important and is simply the result of different evolutions, priorities, and timelines of the projects.
typescript-eslint, exists primarily because of this major difference between the projects.
typescript-eslintexists so that you can use ESLint and TypeScript together, without needing to worry about implementation detail differences wherever possible.
TSLint is a fantastic tool. It is a linter that was written specifically to work based on the TypeScript AST format mentioned above. This has advantages and disadvantages, as with most decisions we are faced with in software engineering!
Palantir, the backers behind TSLint announced in 2019 that they would be deprecating TSLint in favor of supporting
typescript-eslintin order to benefit the community. You can read more about that here: https://medium.com/palantir/tslint-in-2019-1a144c2317a9
The TypeScript Team themselves also announced their plans to move the TypeScript codebase from TSLint to
typescript-eslint, and they have been big supporters of this project. More details at https://github.com/microsoft/TypeScript/issues/30553
If you are looking for help in migrating from TSLint to ESLint, you can check out this project: https://github.com/typescript-eslint/tslint-to-eslint-config
typescript-eslintwork and why do you have multiple packages?
As mentioned above, TypeScript produces a different AST format to the one that ESLint requires to work.
This means that by default, the TypeScript AST is not compatible with the 1000s of rules which have been written by and for ESLint users over the many years the project has been going.
var x: number = 1;
: numbersyntax will be represented in the tree, and this is simply not something that ESLint can understand without additional help.
However, we can leverage the fact that ESLint has been designed with these use-cases in mind!
Knowing we can do this is just the start, of course, we then need to set about creating a parser which is capable of parsing TypeScript source code, and delivering an AST which is compatible with the one ESLint expects (with some additions for things such as
: number, as mentioned above).
The flow and transformations that happen look a little something like this:
ESLint invokes the
parserspecified in your ESLint config (
@typescript-eslint/typescript-estree, an agnostic package that is only concerned with taking TypeScript source code and producing an appropriate AST.
Note: This AST format is more broadly used than just for ESLint. It even has its own spec and is known as ESTree, which is why our package is called
Prettier's TypeScript use-case.
That just about covers the parsing piece! But what about the rules? This is where our plugins come into play.
The short answer is, no.
The great news is, there are many, many rules which will "just work" without you having to change anything about them or provide any custom alternatives.
However, it is super important to be mindful of all of the things we have covered in this README so far.
TypeScript and ESLint have similar purposes
One of the huge benefits of using TypeScript is the fact that type information can be used to assert expected behaviors.
When the transformation steps outlined above take place, we keep references to the original TypeScript AST and associated parser services, and so ESLint rules authors can access them in their rules.
Babel does now support parsing (but not type-checking) TypeScript source code. This is as an alternative to using the TypeScript Compiler. It also supports many other syntaxes, via plugins, which are not supported by the TypeScript Compiler. As mentioned above,
typescript-eslintis powered by the TypeScript Compiler, so we support whatever it does.
The key trade-off can be summarized as
@babel/eslint-parsersupports additional syntax which TypeScript itself does not, but
typescript-eslintsupports creating rules based on type information, which is not available to babel because there is no type-checker.
Because they are separate projects powered by different underlying tooling, they are currently not intended to be used together.
Some of the people involved in
typescript-eslintare also involved in Babel and
I'm so glad you asked!
As you can see at the top of this repo, these packages are already downloaded millions of times per month, and power high profile projects across our industry.
Nevertheless, this is a 100% community-driven project. From the second you install one of the packages from this monorepo, you are a part of that community.
Please be respectful and mindful of how many hours of unpaid work go into building out all of the functionality we have introduced (in brief detail) above.
We can always do better, but providing the glue between two different tools is always extra difficult because both sides come with their own assumptions and priorities.
See an issue? Report it in as much detail as possible, ideally with a clear and minimal reproduction. Think about what information you would need to start solving the problem yourself and take it from there.
If you have the time and the inclination, you can even take it a step further and submit a PR to improve the project.
There are also financial ways to contribute, please see Financial Contributors for more details.
All positive contributions are welcome here!
Please follow the links below for the packages you care about.
typescript-estreeand is designed to be used as a replacement for ESLint's default parser,
@typescript-eslint/parser, allows for TypeScript-specific linting rules to run.
All of the packages are published with the same version number to make it easier to coordinate both releases and installations.
We publish a canary release on every successful merge to master, so you never need to wait for a new stable version to make use of any updates.
Additionally, we promote the to the
latesttag on NPM once per week, on Mondays at 1 pm Eastern.
The latest version under the
The latest version under the
canarytag (latest commit to master) is:
(Note: The only exception to the automated publishes described above is when we are in the final phases of creating the next major version of the libraries - e.g. going from
2.x.x. During these periods, we manually publish
canaryreleases until we are happy with the release and promote it to
The version range of TypeScript currently supported by this parser is
These versions are what we test against.
We will always endeavor to support the latest stable version of TypeScript. Sometimes, but not always, changes in TypeScript will not require breaking changes in this project, and so we are able to support more than one version of TypeScript. In some cases, we may even be able to support additional pre-releases (i.e. betas and release candidates) of TypeScript, but only if doing so does not require us to compromise on support for the latest stable version.
Note that our packages have an open
peerDependencyrequirement in order to allow for experimentation on newer/beta versions of TypeScript.
If you use a non-supported version of TypeScript, the parser will log a warning to the console. If you want to disable this warning, you can configure this in your
Please ensure that you are using a supported version before submitting any issues/bug reports.
See the value of
This project makes an effort to support Active LTS and Maintenance LTS release statuses of Node according to Node's release document. Support for specific Current status releases are considered periodically.
TypeScript ESLint inherits from the the original TypeScript ESLint Parser license, as the majority of the work began there. It is licensed under a permissive BSD 2-clause license.
This project exists thanks to every one of the awesome people who contribute code and documentation:
In addition to submitting code and documentation updates, you can help us sustain our community by becoming a financial contributor [Click here to contribute - every little bit helps!]
Support this project with your organization. Your logo will show up here with a link to your website. [Click here to contribute - every little bit helps!]