About ESLint installation and how to use ESLint with TypeScript:

Hi friends, In this post, I am going to explain how to install ESLint and how to use ESLint with typescript.

• ESLint is a static code analysis tool for identifying problematic patterns found in Javascript code.
• Rules in ESLint are configurable, and customized rules can be defined and loaded.
• ESLint covers both code quality and coding style issues.
• ESLint supports current standards of ECMAScript and experimental syntax from drafts for future standards.
• Code using JSX or TypeScript can also be processed when a plugin or transpiler is used

Installation:

• We can install Eslint using npm or yarn

npm install eslint --save-dev

• We should set up the configuration file after installing the eslint package. If we have already @eslint/config packages in the package.json file, we will make sure to run npm init beforehand.

npm init @eslint/config

• After that we can run eslint on any file or directory like this:

npx eslint yourfile.js

Configuration:

After running npm init @eslint/config, we will have a .eslintrc.{js, yml, json} file in our directory. In it, we will see some rules configured like this:

The names “semi” and “quotes” are the names of the rules in ESLint. The first value is the error level of the rule and can be one of these values:

• “off” or “0” — turn the rule off
• “warn” or “1” — turn the rule on as a warning (doesn’t affect the exit code)
• “error” or “2” — turn the rule on as an error (exit code will be 1)

The three error levels allow you fine-grained control over how ESLint applies rules

Our .eslintrc {js, yml, json} configuration file will also include the line:

Configuring ESLint:

• ESLint is designed to be flexible and configurable for our use case.
• We can turn off every rule and run only with basic syntax validation or mix and match the bundled rules and our custom rules to fit the needs of our project.
• There are two primary ways to configure ESLint:

1. Configuration Comments — use JavaScript comments to embed configuration information directly into a file.
2. Configuration Files — use a JavaScript, JSON, or YAML file to specify configuration information for an entire directory and all of its subdirectories. This can be in the form of a .eslintrc.*file or an eslintConfig field in a package.json file, both of which ESLint will look for and read automatically, or we can specify a configuration file on the command line.

Here are some of the options that you can configure in ESLint:

• Environments — which environments your script is designed to run in. Each environment brings with it a certain set of predefined global variables.
• Globals — the additional global variables your script accesses during execution.
• Rules — which rules are enabled and at what error level.
• Plugins — which third-party plugins define additional rules, environments, configs, etc. for ESLint to use.

All of these options give you fine-grained control over how ESLint treats your code.

Configuration file format:

ESLint supports configuration files in several formats:

• JavaScript — use .eslintrc.js and export an object containing our configuration.
• JavaScript (ESM) — use .eslintrc.cjs when running ESLint in JavaScript packages that specify “type”:module” in their package.json. Note that ESLint does not support ESM configuration at this time.
• YAML — use .eslintrc.yaml or .eslintrc.yml to define the configuration structure.
• JSON — use .eslintrc.json to define the configuration structure. ESLint’s JSON files also allow JavaScript-style comments.
• package.json — create an eslintConfig property in your package.json file and define your configuration there.

If there are multiple configuration files in the same directory, ESLint will only use one. The priority order is as follows:

1. . eslintrc.js
2. .eslintrc.cjs
3. .eslintrc.yaml
4. .eslintrc.yml
5. .eslintrc.json
6. package.json

How to use ESLint with TypeScript:

ESLint is a JavaScript linter that we can use to lint either TypeScript or JavaScript code.

Intro

Formatting is one of several concerns in the efforts to write clean code. It is one of those things that we can set up right off the bat and establish a standard for our project.

ESLint and TSLint

ESLint is a JavaScript linter that enables us to enforce a set of style, formatting, and coding standards for our codebase. It looks at our code and tells us when we’re not following the standard that we set in place.

We may have also heard of TSLint, the TypeScript equivalent. In 2019, the team behind TSlint decided that they would no longer support it.

The reason, primarily, is because ESLint exists, and there was a lot of duplicate code between projects with the same intended purpose.

Installation and setup

Run the following commands to set up ESLint in our TypeScript project.

npm install --save-dev eslint @typescript-eslint/parser @typescript-eslint/eslint-plugin

Create a .eslintrc file.

touch .eslintrc

In it, use the following starter config.

Ignoring files, we don’t want to lint

Create a .eslintignore in order to prevent ESLint from linting stuff we don’t want it to.

touch .eslintignore

Then add the things we want to ignore. In the following code sample, we’re ignoring the dist/ folder that contains the compiled TypeScript code. If you’re compiling your TypeScript code to a different folder, make sure to use that instead of dist.

Adding a lint script

In our project package.json, let's add a lint script in order to lint all TypeScript code.

Let’s run the following command.

npm run lint

Adding a rule

In .eslintrc, add a new attribute to the JSON object called “rules”.

Using rules in a real-life project

There is a reason that all three of these modes exist. When we set the linter to off for a rule, it’s because we and our team probably don’t care about the rule in a particular base configuration we’re using (we’re currently using the ESLint recommended config but we can also go and use Shopify’s, Facebook’s or several other companies’ configs as starting points instead).

When we set the rule to error — 2, it means that we don’t want the code that breaks our coding conventions to even make it into the repo at all. I think this is a great act of professionalism and empathy towards the codebase, our fellow teammates, and future maintainers. A popular approach to actually enforce code conventions with this tool is to set up our project with a tool like Husky so that when a teammate tries to commit code or push code, we can tell our linter to check the code first before the operation executes. It’s a great habit, though sometimes if the rules are overly restrictive, it can slow down and annoy our teammates.

To remedy overly restrictive rules, the warn — 1

Add a plugin (features)

ESLint also allows us to add features to our config. Example: no-loop

Fixed linted code with Eslint

We might have noticed that at the end of the error message, it says “2 errors and 0 warnings potentially fixable with the — fix option.”

You can run ESLint and tell it to fix things that it’s able to fix at the same time.

Using the — fix option, let’s add a new script to our package.json called lint-and-fix.

Running this command against our code, I expect that it will put a semicolon on the console.log statement that we had.

Let’s run it.

npm run lint-and-fix

Conclusion

I hope, In this post, we have learned a lot of fundamental things about eslint, Thank you for reading this blog, See you soon.