Linting: the spell check of code. Once you have it, you can’t imagine how you ever lived without it. Useful for solo developers and large teams, linting keeps your code consistent and prevents bugs from getting anywhere near your production build.
Before Angular 11, linting was supported via a library called TSLint. However, the TSLint team deprecated the project in 2019 and Angular followed suit in November 2020. Fortunately, thanks to tools from the Angular ecosystem migrating to ESLint is easier than you think.
Want to jump straight to how to migrate from TSLint to ESLint? Click here
Lint? Like Dryer Lint?
Linting is a process which checks your code for adherence to a defined set of style rules. Common linting rules are restrictions on line length or whitespace, as well as syntax checks like semicolons at the end of lines.
Amusingly, the term is derived from the same fuzzy lint that clogs up your dryer. Just like a dryer’s lint trap catches bits of fluff that could accumulate and burn your house down, a code linter catches small errors that might crash your website.
Why Replace TSLint?
TSLint has been around for years, why are things changing now? A big reason: ESLint is compatible with both JavaScript and TypeScript. This makes jumping between the two languages a bit easier, especially for new developers. The core concept of TypeScript is a 100% compatible superset of JavaScript, so parity in tooling keeps the two languages in step.
I’ll add that I find ESLint’s config structure to be a bit easier to read. TSLint also has a dependency on Codelyzer, where ESLint does not. The TSLint team has a great write up on the move to ESLint.
Migrations of this sort often send chills down developers’ spines. Perhaps you’ve spent years tweaking your linting settings so they’re just right. Now you have to do it all over again? Definitely not! We’ll use angular-eslint to make migration a breeze.
Migrating an Existing Angular 10+ Project
The community-driven library angular-eslint provides an awesome set of schematics for migrating your existing Angular projects to ESLint. Currently, only Angular 10.1.0 is supported. If your project is running an older version of Angular, come back to this blog once you’ve upgraded.
The biggest practical difference between TSLint and ESLint is the format of their configuration file, which stores the rules the linter uses to validate your code. We’ll also need to update Angular to use ESLint when we run “ng lint”. Fortunately, angular-eslint’s schematic handles both of these changes!
A quick note: the changes below will update your angular.json file. Unless you have your project configuration memorized, I recommend backing up this file or making these changes in a dedicated branch, just in case! For testing purposes, I’d also suggest writing a few lines of code that will intentionally throw linting errors.
To install the schematics, navigate to the root of your project and run the following Angular CLI command:
ng add @angular-eslint/schematics
Next, run the following to generate a new ESLint file based on the contents of your project’s existing TSLint config:
ng g @angular-eslint/schematics:convert-tslint-to-eslint
If you see any errors in the terminal, it is likely that ESLint was unable to map a rule. Your experience may vary depending on the degree of customization in your TSLint configuration.
Once complete, you should see a new “.eslintrc.json” file at the root of your project and your angular.json “lint” sections should now reference @angular-eslint.
To test, run the following command from your project.
ng lint
That’s it! You should see linting run against your codebase using the same rules previously used by TSLint.
Wait, why is this new ESLint config so short?
If you’re used to using the tslint.json shipped with Angular, the newly generated ESLint config file may seem suspiciously short. This is mostly a result of the angular-eslint library, which provides you with an “override” linting file for adding project level rules while tucking away most of the boilerplate Angular config.
I personally love this approach, as it makes it much easier to find project-level linting rules. More info on properly customizing ESLint can be found on the angular-eslint GitHub page.
When you’re confident that your new ESLint configuration is to your liking, feel free to remove TSLint and Codelyzer from your project.
Using ESLint for a New Angular Project
As of the publication of this blog, the Angular CLI still configures new projects for use with TSLint. If you’d like to create a new project with ESLint instead, you can leverage angular-eslint’s schematics using the following command:
ng new --collection=@angular-eslint/schematics
This schematic runs after your new project is created, mapping the default TSLint configuration file to a new ESLint file and updating your project’s angular.json (it may take a few seconds to complete).
Wrap-up
Linting is an indispensable tool for producing quality code, and the migration to ESLint ensures our Angular projects will continue to stay neat and tidy as the TypeScript ecosystem evolves.
Do you have thoughts?
We’d love to hear them! Join our Community Discord to continue the ESLint conversation.
Still have questions about migrating to ESLint? Experiencing other Angular upgrade headaches? We’d love to help! Send us an email at contact@bitovi.com.
development
Previous Post
