Eslint typescript config example

Setting up ESLINT with TS/JS in your React project in 2023

ESLINT: Does not matter if you are a seasoned or a novice developer, ESLINT is definitely a term you have come across or heard of at the very least. Even I had heard of it a lot and even used it in applications that already had it configured but never had the liberty and or the chance to set it up on my own in a bare project. And that is exactly what we shall be doing today using the following tools: ESLINT is a pluggable linting tool for JS as well as JSX (basically React) which helps you detect possible errors in your code ranging from a wide array of possibilities such as unused variables in files, illegal comparisons, etc. PRETTIER is probably the most popular code formatter to enforce a certain and consistent style guide in your codebase. HUSKY in its own words is a simple tool to improve your commits and more by making use of git hooks.

SETTING UP ESLINT

It’s as simple as running the following command in a terminal at the root of your project: npm init @eslint/config Once you execute it, you will be prompted with a bunch of questions as follows:-
Based on your requirements and environment, answer the questions accordingly. At least with eslint version 8.0.1, you are only presented with 2 style guides: standard and XO.
Personally, I prefer the standard styling guide but at any give time, it is a personal choice and as such feel free to choose any from a bunch of available options. Once all dependencies are installed, ensure that you have the following packages added as devDependencies to your project:

• @typescript-eslint/eslint-plugin
• @typescript-eslint/parser
• eslint
• eslint-config-standard-with-typescript
• eslint-plugin-import
• eslint-plugin-n
• eslint-plugin-promise
• eslint-plugin-react

At the time of writing this article, eslint latest version is 8.0.1 and there is a high chance that you may not get @typescript-eslint/parser added directly. If that is the case, do not worry. Just add the same as a dev dependency using

npm i —save-dev @typescript-eslint/parser

Following is a screenshot of the linter configuration that I work with. Feel free to go about the rules section and tweak it as per your flow. However, it is advisable that you do not go about changing the rules cause any style guide is written keeping certain things in mind but like all things, it is your call ultimately.

< "env": < "browser": true, "es2021": true >, "extends": [ "plugin:react/recommended", "standard-with-typescript", "plugin:import/typescript", "plugin:prettier/recommended" ], "parser": "@typescript-eslint/parser", "overrides": [], "parserOptions": < "ecmaVersion": "latest", "sourceType": "module", "project": "./tsconfig.json" >, "plugins": ["react", "prettier"], "rules": < "@typescript-eslint/triple-slash-reference": "off" >> 

NOTE: Do remember to add a .eslintignore file and keep non-essential files such as build, node_modules, dist, etc. in there otherwise the linter will keep yelling at you to fix those changes as well.

SETTING UP PRETTIER

This is comparatively a simple process cause most of the setup for prettier was already taken care of when we set up eslint and the related config file. Hit up the following command:-

npm i —save-dev prettier eslint-config-prettier eslint-plugin-prettier

Add a .prettierrc.js file as follows:

• Just like a .eslintignore, add a .prettierignore file containing elements that don’t need to be checked.
• Don’t forget to check the format on save setting in VSCode to allow prettier to enforce your changes automatically when you save your code.

SETTING UP HUSKY**

We are almost there. This is probably the trickiest and yet the easiest part of everything. The Husky CLI makes it really easy to set things up. Once again, power up a terminal and run the following command:-
npx husky-init && npm install

This creates a .husky folder at your root level with an existing file called pre-commit and this is the file where you want to add some things so that your codebase is scanned for issues before you are able to commit your code. But before we jump to this file, you wanna edit the scripts part of your package.json by adding the following lines:

"lint": "eslint .", "lint:fix": "eslint --fix .", "prettier": "prettier --write .", 

Once this is done, you head over to the pre-commit file discussed earlier and add a simple line over there:
npm run lint
which ultimately translates that before you commit your changes, run the lint script as specified in the package.json file.

To be absolutely sure of things, before committing your code, run the following commands in order:
npm run prettier

These will make sure that your code is at least formatted properly and devoid of as many errors that eslint could have fixed automatically for you. If you still see errors on your terminal, head over to the erroneous files and fix the issues manually and then only can you move forward with committing your code.

And that wraps it up. You are all done towards making and keeping your code well maintained. HAPPY HACKING!

Источник

Configurations

ESLint shareable configurations exist to provide a comprehensive list of rules settings that you can start with. @typescript-eslint/eslint-plugin includes built-in configurations you can extend from to pull in the recommended starting rules.

With the exception of all , strict , and strict-type-checked , all configurations are considered «stable». Rule additions and removals are treated as breaking changes and will only be done in major version bumps.

Getting Started​

Projects Without Type Checking​

If your project does not enable typed linting, we suggest enabling the recommended and stylistic configurations to start:

module.exports =   extends: [ 'eslint:recommended', 'plugin:@typescript-eslint/recommended', 'plugin:@typescript-eslint/stylistic', ], >; 

If a majority of developers working on your project are comfortable with TypeScript and typescript-eslint, consider replacing recommended with strict .

Projects With Type Checking​

If your project enables typed linting, we suggest enabling the recommended-type-checked and stylistic-type-checked configurations to start:

module.exports =   extends: [ 'eslint:recommended', 'plugin:@typescript-eslint/recommended-type-checked', 'plugin:@typescript-eslint/stylistic-type-checked', ], >; 

If a majority of developers working on your project are comfortable with TypeScript and typescript-eslint, consider replacing recommended-type-checked with strict-type-checked .

Recommended Configurations​

We recommend that most projects should extend from one of:

• recommended : Recommended rules for code correctness that you can drop in without additional configuration.
• recommended-type-checked : Additional recommended rules that require type information.
• strict : Additional strict rules that can also catch bugs but are more opinionated than recommended rules.
• strict-type-checked : Additional strict rules require type information.

Additionally, we provide a stylistic config that enforces concise and consistent code. We recommend that most projects should extend from either:

• stylistic : Stylistic rules you can drop in without additional configuration.
• stylistic-type-checked : Additional stylistic rules that require type information.

These configurations are our recommended starting points, but you don’t need to use them as-is. ESLint allows configuring own rule settings on top of extended configurations. See ESLint’s Configuring Rules docs.

recommended ​

Recommended rules for code correctness that you can drop in without additional configuration. These rules are those whose reports are almost always for a bad practice and/or likely bug. recommended also disables core ESLint rules known to conflict with typescript-eslint rules or cause issues in TypeScript codebases.

module.exports =   extends: ['plugin:@typescript-eslint/recommended'], >; 

See configs/recommended.ts for the exact contents of this config.

recommended-type-checked ​

Contains all of recommended along with additional recommended rules that require type information. Rules newly added in this configuration are similarly useful to those in recommended .

module.exports =   extends: ['plugin:@typescript-eslint/recommended-type-checked'], >; 

See configs/recommended-type-checked.ts for the exact contents of this config.

strict ​

Contains all of recommended , as well as additional strict rules that can also catch bugs. Rules added in strict are more opinionated than recommended rules and might not apply to all projects.

module.exports =   extends: ['plugin:@typescript-eslint/strict'], >; 

See configs/strict.ts for the exact contents of this config.

We recommend a TypeScript project extend from plugin:@typescript-eslint/strict only if a nontrivial percentage of its developers are highly proficient in TypeScript.

strict-type-checked ​

Contains all of recommended , recommended-type-checked , and strict , along with additional strict rules that require type information. Rules newly added in this configuration are similarly useful (and opinionated) to those in strict .

module.exports =   extends: ['plugin:@typescript-eslint/strict-type-checked'], >; 

See configs/strict-type-checked.ts for the exact contents of this config.

We recommend a TypeScript project extend from plugin:@typescript-eslint/strict-type-checked only if a nontrivial percentage of its developers are highly proficient in TypeScript.

stylistic ​

Rules considered to be best practice for modern TypeScript codebases, but that do not impact program logic. These rules are generally opinionated about enforcing simpler code patterns.

module.exports =   extends: ['plugin:@typescript-eslint/stylistic'], >; 

See configs/stylistic.ts for the exact contents of this config.

stylistic-type-checked ​

Contains all of stylistic , along with additional stylistic rules that require type information. Rules newly added in this configuration are similarly opinionated to those in stylistic .

module.exports =   extends: ['plugin:@typescript-eslint/stylistic-type-checked'], >; 

See configs/stylistic-type-checked.ts for the exact contents of this config.

Other Configurations​

typescript-eslint includes a few utility configurations.

all ​

Enables each the rules provided as a part of typescript-eslint. Note that many rules are not applicable in all codebases, or are meant to be configured.

See configs/all.ts for the exact contents of this config.

We do not recommend TypeScript projects extend from plugin:@typescript-eslint/all . Many rules conflict with each other and/or are intended to be configured per-project.

base ​

A minimal ruleset that sets only the required parser and plugin options needed to run typescript-eslint. We don’t recommend using this directly; instead, extend from an earlier recommended rule.

This config is automatically included if you use any of the recommended configurations.

See configs/base.ts for the exact contents of this config.

disable-type-checked ​

A utility ruleset that will disable type-aware linting and all type-aware rules available in our project. This config is useful if you’d like to have your base config concerned with type-aware linting, and then conditionally use overrides to disable type-aware linting on specific subsets of your codebase.

See configs/disable-type-checked.ts for the exact contents of this config.

If you use type-aware rules from other plugins, you will need to manually disable these rules or use a premade config they provide to disable them.

module.exports =   extends: [ 'eslint:recommended', 'plugin:@typescript-eslint/eslint-recommended', ], overrides: [   files: ['*.js'], extends: ['plugin:@typescript-eslint/disable-type-checked'], >, ], >; 

eslint-recommended ​

This ruleset is meant to be used after extending eslint:recommended . It disables core ESLint rules that are already checked by the TypeScript compiler. Additionally, it enables rules that promote using the more modern constructs TypeScript allows for.

module.exports =   extends: [ 'eslint:recommended', 'plugin:@typescript-eslint/eslint-recommended', ], >; 

This config is automatically included if you use any of the recommended configurations.

See configs/eslint-recommended.ts for the exact contents of this config.

Suggesting Configuration Changes​

If you feel strongly that a specific rule should (or should not) be one of these configurations, please file an issue along with a detailed argument explaining your reasoning.

Formatting​

None of the preset configs provided by typescript-eslint enable formatting rules (rules that only serve to enforce code whitespace and other trivia). We strongly recommend you use Prettier or an equivalent for formatting your code, not ESLint formatting rules. See What About Formatting? > Suggested Usage.

Источник