{"id":1915,"date":"2022-05-22T12:52:37","date_gmt":"2022-05-22T10:52:37","guid":{"rendered":"https:\/\/nguenkam.com\/blog\/?p=1915"},"modified":"2022-05-22T14:19:36","modified_gmt":"2022-05-22T12:19:36","slug":"migration-from-tslint-to-eslint","status":"publish","type":"post","link":"https:\/\/nguenkam.com\/blog\/index.php\/2022\/05\/22\/migration-from-tslint-to-eslint\/","title":{"rendered":"Migration from TSLint to ESLint"},"content":{"rendered":"\n

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.<\/p>\n\n\n\n

Before Angular 11, linting was supported via a library called TSLint<\/a>. 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<\/a> is easier than you think.<\/p>\n\n\n\n

Why Replace TSLint?<\/strong><\/h4>\n\n\n\n

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.<\/p>\n\n\n\n

ESLint\u2019s config structure is a bit easier to read. TSLint also has a dependency on Codelyzer<\/a>, where ESLint does not<\/p>\n\n\n\n

Migrating an Existing Angular 10+ Project<\/strong><\/h4>\n\n\n\n

 We\u2019ll use angular-eslint<\/a> to make migration a breeze.<\/p>\n\n\n\n

The community-driven library angular-eslint<\/a> provides an awesome set of schematics<\/a> for migrating your existing Angular projects to ESLint. Currently, only Angular 10.1.0 is supported<\/strong>. If your project is running an older version of Angular, then you\u2019ve to upgrade it first.<\/p>\n\n\n\n

The biggest practical difference between TSLint<\/strong><\/em> and ESLint<\/strong><\/em> is the format of their configuration file, which stores the rules the linter uses to validate your code. We\u2019ll also need to update Angular to use ESLint when we run \u201c<\/strong><\/span>ng lint<\/span><\/strong>\u201d<\/strong><\/span><\/em>. Fortunately, angular-eslint\u2019s schematic handles both of these changes!<\/p>\n\n\n\n

ps: <\/em><\/strong> 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! <\/em>For testing purposes, you can also write a few lines of code that will intentionally throw linting errors.<\/p>\n\n\n\n

To install the schematics, navigate to the root of your project and run the following Angular CLI <\/a>command:<\/p>\n\n\n\n

ng add @angular-eslint\/schematics<\/code><\/pre>\n\n\n\n
Next, run the following to generate a new ESLint file based on the contents of your project\u2019s existing TSLint config:<\/p>\n\n\n\n
ng g @angular-eslint\/schematics:convert-tslint-to-eslint<\/code><\/pre>\n\n\n\n
If you see any errors in the terminal, it is likely that ESLint was unable to map a rule<\/a>. Your experience may vary depending on the degree of customization in your TSLint configuration.<\/p>\n\n\n\n
Once complete, you should see a new \u201c.eslintrc.js<\/strong><\/em>o<\/em>n<\/strong>\u201d file at the root of your project and your angular.json \u201clint\u201d <\/strong><\/em>sections should now reference @angular-eslint<\/strong><\/em>.<\/p>\n\n\n\n
To test, run the following command from your project.<\/p>\n\n\n\n
ng lint<\/code><\/pre>\n\n\n\n
It will probably find some issues, like trailing spaces, and naming convention rules. Most of these can be automatically fixed with the following command. Is your working tree clean? Run this command:<\/p>\n\n\n\n
ng lint --fix<\/code><\/pre>\n\n\n\n
You should now see some changed files. ESLint fixes everything it can but it won’t change everything for you. That’s ok; you shouldn’t have too many new things to fix. If you have some false positives, don’t worry, these won’t prevent your build from succeeding.<\/em><\/p>\n\n\n\n
That\u2019s it! You should see linting run against your codebase using the same rules previously used by TSLint.<\/p>\n\n\n\n
Wait, why is this new ESLint config so short?<\/strong><\/h4>\n\n\n\n
If you\u2019re 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 \u201coverride\u201d linting file for adding project level rules while tucking away most of the boilerplate Angular config. <\/p>\n\n\n\n
More info on properly customizing ESLint can be found on the angular-eslint GitHub page<\/a>.<\/p>\n\n\n\n
When you\u2019re confident that your new ESLint configuration is to your liking, feel free to remove TSLint and Codelyzer from your project.<\/p>\n\n\n\n
Using ESLint for a New Angular Project<\/span><\/strong><\/h4>\n\n\n\n
The Angular CLI still configures new projects for use with TSLint. If you\u2019d like to create a new project with ESLint instead, you can leverage angular-eslint\u2019s schematics using the following command:<\/p>\n\n\n\n
ng new --collection=@angular-eslint\/schematics<\/code><\/pre>\n\n\n\n
This schematic runs after your new project is created, mapping the default TSLint configuration file to a new ESLint file and updating your project\u2019s angular.json (it may take a few seconds to complete).<\/p>\n\n\n\n
FAZIT<\/h4>\n\n\n\n
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. Future versions of Angular and Typescript will no longer be supported by TSLint.<\/p>\n\n\n\n
<\/p>\n\n\n\n
Using ESLint with Angular in VScode<\/strong><\/h4>\n\n\n\n
First, install this ESLint extension<\/a>: it’s the top result if you search “eslint”. The author is a guy named Dirk but it is a Microsoft maintained package.<\/p>\n\n\n\n
\"\"<\/figure><\/div>\n\n\n\n
Next, open the command palette (cmd\/ctrl + shift + P) and type “ESLint: Manage Library Execution”.<\/p>\n\n\n\n
You will be prompted by VScode to allow ESLint to run. You can choose “Allow” to just have it run in this project. Don’t choose “Allow Everywhere” unless you plan to convert all<\/em><\/strong> your Angular projects to ESLint right away.<\/p>\n\n\n\n
\"\"<\/figure><\/div>\n\n\n\n
PS<\/em><\/strong>: Note that if you would like ESLint to work on your html templates, you will need to make the following change to your VScode settings:<\/em><\/p>\n\n\n\n
\"\"<\/figure><\/div>\n\n\n\n
<\/div>\n\n\n\n
Here you can learn more about TypeScript ESLint Rules : <\/em> https:\/\/typescript-eslint.io\/rules\/<\/a><\/p>\n\n\n\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
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. Before Angular 11, linting was supported via a library called TSLint. However, the TSLint team deprecated the project […]<\/p>\n","protected":false},"author":1,"featured_media":1918,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[1,37],"tags":[546,252,248],"_links":{"self":[{"href":"https:\/\/nguenkam.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1915"}],"collection":[{"href":"https:\/\/nguenkam.com\/blog\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/nguenkam.com\/blog\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/nguenkam.com\/blog\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/nguenkam.com\/blog\/index.php\/wp-json\/wp\/v2\/comments?post=1915"}],"version-history":[{"count":4,"href":"https:\/\/nguenkam.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1915\/revisions"}],"predecessor-version":[{"id":1924,"href":"https:\/\/nguenkam.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1915\/revisions\/1924"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/nguenkam.com\/blog\/index.php\/wp-json\/wp\/v2\/media\/1918"}],"wp:attachment":[{"href":"https:\/\/nguenkam.com\/blog\/index.php\/wp-json\/wp\/v2\/media?parent=1915"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/nguenkam.com\/blog\/index.php\/wp-json\/wp\/v2\/categories?post=1915"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/nguenkam.com\/blog\/index.php\/wp-json\/wp\/v2\/tags?post=1915"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}