Linting in TypeScript using ESLint and Prettier

Editor’s note: This article was last updated on 26 September 2023 to provide information about the latest version of ESLint, v8.5 at the time of writing.

As developers, we usually start a project by adding configurations and scripts for linting, then formatting and type checking for our codebase syntax and style.

This process is even more important when working on a team because everyone needs to be on the same page for codebase syntax and style. Also, to ensure that there are no typos or bugs when our app is in production, we should type check our code along the way.

Having a formatting tool, a linting tool, and TypeScript helps us automate this process. In this article, we’ll use ESLint and TypeScript, and we’ll also see how to add Prettier and additional tooling that will automate this process for us.

To jump ahead:

• Compiling TypeScript code
• What is linting?
• What is ESLint?
• Linting with ESLint
• What is Prettier?
• Why do we need Prettier with ESLint?
• Integrating Prettier
• Avoiding conflicts when working with ESLint and Prettier
• ESLint vs. Prettier

N.B., There is a compatibility issue with specific versions of Node and the latest versions of ESLint and Prettier, so make sure you’re running a Node version >= 16.0.0 when following the code sections later.

Compiling TypeScript code

Typescript is a superset of JavaScript that helps us with static type checking at compile time. TypeScript will give you a better development experience thanks to auto-completion in your editor. TypeScript also helps you maintain the code in your large codebases.

First, we need a compiler to turn TypeScript code into JavaScript so the browser can read it. Let’s install a dependency using your favorite package manager.

Head over to a suitable folder on your computer and run one of the following commands in your terminal:

#npm
npm install --save-dev typescript

#yarn
yarn add typescript --dev

Upon installation, you’ll see a new entry to the devDependencies attribute of your package.json file as:

{
  "name": "Linting TypeScript with ESLint",
  "version": "1.0.0",
  "devDependencies": {
    "typescript": "^5.2.2"
  }
}

If you want to verify that it’s been installed, you can run this to check the version:

npx tsc --version
# Version 5.2.2

In your folder, create an index.ts file in the src directory and add the following TypeScript code:

// src/index.ts
const favoriteFruits: string[] = ["apple", "strawberry", "orange"];

function addFruit(fruit: string) {
  favoriteFruits.push(fruit);
}

We can compile the TypeScript code to JavaScript by running the following command in the terminal:

npx tsc src/index.ts

Right after that, we’ll see a newly generated JavaScript file in the same directory as the TypeScript file:

// src/index.js
var favoriteFruits = ["apple", "strawberry", "orange"];

function addFruit(fruit) {
    favoriteFruits.push(fruit);
}

By default, the compiler will create JavaScript files side-by-side with the TypeScript source file that created it. This is not a good idea because you’ll end up mixing your build results with your source code.

So, let’s change some default compiler settings, starting from where we want to put our compiled code, which JavaScript level is targeted to be transpiled (by default: ECMAScript 3), and which files we want to compile.

There are two ways to create your TypeScript compiler settings:

1. Run the following command in the terminal: npx tsc --init. This will generate a default TypeScript configuration file
2. Create a file called tsconfig.json at the root directory of your project and include your settings

In this case, I’ll create the TypeScript compiler settings manually. However, I would encourage you to choose the first option. It will create the config file with some recommended options — all options are described with comments explaining what they do.

You can modify these settings as you need to. Check out the full list of supported compiler options, and you can play around in the TypeScript playground:

// tsconfig.json
{
  "compilerOptions": {
    "outDir": "dist", // where to put the compiled JS files
    "target": "ES2020", // which level of JS support to target
    "module": "CommonJS", // which system for the program AMD, UMD, System, CommonJS

    // Recommended: Compiler complains about expressions implicitly typed as 'any'
    "noImplicitAny": true, 
  },
  "include": ["src"], // which files to compile
  "exclude": ["node_modules"], // which files to skip
}

Congratulations! Now, you can start writing TypeScript and compiling it to JavaScript by running npx tsc.

You can include the above command in your scripts to make it easier to run. Go to package.json and add the --watch flag to watch the files for changes. Keep in mind that everything that is described in compilerOptions can be passed into the command line using CLI flags:

// package.json
{
  "name": "Linting TypeScript with ESLint",
  "version": "1.0.0",
  "devDependencies": {
    "typescript": "^4.9.4"
  },
  "scripts": {
    "dev": "tsc --watch"
  }
}

What is linting?

Code linting is the automated analysis of source code to find and report programmatic and stylistic errors. It helps reduce errors, thereby improving the quality of code delivered. Code linting has numerous benefits, including error detection, enforcing best practices, and enforcing coding style amongst others.

Linting helps catch errors by performing syntax checks, checking code quality, and ensuring consistency in formatting style. It is advisable to use always in projects to enforce a coding style.

What is ESLint?

One of the most popular tools for linting is ESLint, which will analyze your code to find potential bugs and improve your code quality by defining coding conventions and then automatically enforcing them. Let’s see how to install ESLint into our TypeScript project.

First, install the following dependencies to your devDependencies:

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

• eslint: ESLint core library
• @typescript-eslint/parser: A parser that allows ESLint to understand TypeScript code
• @typescript-eslint/eslint-plugin: Plugin with a set of recommended TypeScript rules

Similar to Typescript compiler settings, you can either use the command line to generate a configuration file using the --init flag from ESLint or create it manually. Either way, it’s mandatory to have your ESLint configuration file.

Let’s create a configuration file using the CLI. Run the following command in the terminal:

npx eslint --init

Next, you will see a series of questions that allow you to adjust the configuration file based on your preferences:

• How would you like to use ESLint?
• What type of modules does your project use?
• Which framework does your project use?
• Does your project use TypeScript?
• Where does your code run?
• How would you like to define a style for your project?

Based on the options selected, the ESLint CLI will create a .eslintrc configuration file in the project’s root directory with some default settings. If you already have your favorite settings, you can replace some of the options in the configuration file.

You can also explore the full list of ESLint settings available for the configuration file.

Linting with ESLint

For this article, replace the default settings in the configuration file with this:

// .eslintrc
{
  "parser": "@typescript-eslint/parser",
  "parserOptions": {
    "ecmaVersion": 12,
    "sourceType": "module"
  },
  "plugins": ["@typescript-eslint"],
  "extends": ["eslint:recommended", "plugin:@typescript-eslint/recommended"],
  "rules": {

  },
  "env": {
    "browser": true,
    "es2021": true
  },
}

• parser: This specifies a parser for ESLint to use when analyzing the code
• parserOptions: Specifies what JS language options you want to support, such as the version of ECMAScript syntax you want to use
• plugins: This is where you define plugins to use
• extends: Tells ESLint what configuration is set to extend from. The order matters as the last extend option will override the previous ones in any conflicting configurations
• env: Specifies which environments your code will run in

When we add an ESLint rule, it overrides the configuration defined in the extends list. Let’s add a couple of rules to see how it works:

// .eslintrc
{
  "parser": "@typescript-eslint/parser",
  "parserOptions": {
    "ecmaVersion": 12,
    "sourceType": "module",
  },
  "plugins": ["@typescript-eslint"],
  "extends": ["eslint:recommended", "plugin:@typescript-eslint/recommended"],

  "rules": {
    "@typescript-eslint/no-unused-vars": "error",
    // to enforce using type for object type definitions, can be type or interface 
    "@typescript-eslint/consistent-type-definitions": ["error", "type"], 
  },

  "env": {
    "browser": true,
    "es2021": true
  }
}

In short, the first rule we apply is assigned to a value of error, but error is not the only value we can assign — we have three options:

• off or 0: Turn off the rule completely
• warn or 1: Treat the rule as a warning, but it won’t fail when running a linter
• error or 2: Treat the rule as an error. It will fail when running a linter

N.B., In some ESLint rules, like the second rule, you would need to set additional options to use an array literal syntax.

You can tell ESLint to lint your code using the following command: eslint --ext .js,.ts. The ext flag is used to specify which file extensions ESLint should consider when searching for files in the target directory. In this case, we include TypeScript file extensions: .ts (by default, it’s .js)

Now you can add a lint script into your package.json with the command above:

// package.json
{
  "name": "Linting TypeScript with ESLint",
  "version": "1.0.0",
  "scripts": {
    "dev": "tsc --watch",
    "lint": "eslint --ext .js,.ts",
  },
  "devDependencies": {
    "@typescript-eslint/eslint-plugin": "^6.7.3",
    "@typescript-eslint/parser": "^6.7.3",
    "eslint": "^8.50.0",
    "typescript": "^5.2.2"
  }
}

You’ll find that some files don’t need to be linted at all, such as your dist folder, so you can prevent linting by creating a .eslintignore file and adding the folders or files you want to ignore:

node_modules
dist

This often matches with your .gitignore file content, so to have a single source of truth, you can update the lint script to use the --ignore-path flag:

// package.json
{
  // ...
  "scripts": {
    "lint": "eslint --ignore-path .eslintignore --ext .js,.ts"
   },
  // ...
}

Now you’re ready to go! I suggest you integrate ESLint into whatever editor you use. If that’s VSCode, go to the extension and install the ESLint extension.

Once you’ve installed and enabled it, you’ll see what errors you’ve made in your code without running the script that is underlined with a red line.

You’ll see that the ESLint error message is printed inline in the editor; that’s another extension called Error Lens, which highlights the entire line and shows the error message immediately instead of hovering with the pointer to see it:

Another feature of ESLint is that it can automatically fix code when you hover and right-click Quick fix, or you can hit command and +:

Manually fixing all of the errors that have broken your rules can be tedious, but you can run the following command that will tell ESLint to fix what it can:

npm run lint --fix

Tip: You can pass parameters using double dashes -- for npm scripts, which will be received as parameters for the script that npm executes:

npm run <command> [-- <args>]

What is Prettier?

Prettier is a well-known code formatter that supports a variety of different programming languages. It helps us avoid manually formatting our code by automatically formatting it based on a specified code style.

Nowadays, it’s common to use ESLint and Prettier together, and we will learn how to integrate Prettier with ESLint. First, let’s look at the difference between both and why they can be beneficial together.

Why do we need Prettier with ESLint?

The primary function of a linter is to improve your code by analyzing it and alerting you to any potential issues based on customizable or pre-defined rulesets. These rulesets, or rules, allow development teams to maintain a consistent coding style and identify potential bugs caused by inconsistent coding styles.

On the other hand, a code formatter like Prettier ensures a consistent style by parsing your code and re-printing it according to its rules. For example, you can specify a style that all JavaScript statements must end with a semicolon; the code formatter will automatically add the semicolon to all statements without one.

In essence, you can use ESLint to specify rulesets that must be adhered to and then use Prettier to fix cases in your code where these rulesets are broken.

Integrating Prettier

With that covered, let’s add Prettier to our project. Run the following command in the terminal:

npm install --save-dev prettier

Compared to ESLint, Prettier doesn’t need a config file, meaning you can run and use it straight away. However, if you want to set a config, you will need to create a file called .prettierrc.json in the project’s root directory, where you can define your format options.

You can take a look at the full list of format options and play around in the Prettier Playground:

// .prettierrc.json
{
  "semi": false, // Specify if you want to print semicolons at the end of statements
  "singleQuote": true, // If you want to use single quotes
  "arrowParens": "avoid", // Include parenthesis around a sole arrow function parameter
}

Next, we are going to start formatting our code using Prettier in the command line:

npx prettier --write src/index.ts
# src/index.ts 37ms

I added a write flag to overwrite the TypeScript file, otherwise, it won’t overwrite it and will only log the formatted code in your CLI.

Let’s add the Prettier command to our scripts, just as we did for TypeScript and ESLint. Let’s also support all files that end in .ts, .js, and .json, and ignore the same files and directories as gitignore (or you can create a .prettierignore file):

// package.json

{
  // ...
  "scripts": {
    "dev": "tsc --watch",
    "lint": "eslint --ext .js,.ts .",
    "format": "prettier --ignore-path .gitignore --write \"**/*.+(js|ts|json)\""
  },
  // ...
}

Now, you can run the npm run format command to format and fix all your code. But what if we would like to format the code right after saving your files?

That’s possible! In VSCode, go to the extensions tab, look for the Prettier extension, and ensure it’s enabled. Once enabled, we need to configure a few things in VSCode.

You can open your command palette (Command + Shift + P) and look for Preferences: Open User Settings (JSON). Then you’ll need to change your editor’s default formatter and add an extra config to format code when you save your files:

// settings.json
{
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "editor.formatOnSave": true,
  ...
}

Avoiding conflicts when working with ESLint and Prettier

You’ll likely run into an issue when a Prettier and ESLint rule overlap. You can try to auto-format your code, but it will show you some conflicts with ESLint.

The best solution here is to use the eslint-config-prettier plugin to disable all ESLint rules that are irrelevant to code formatting, as Prettier is already good at it:

npm install --save-dev eslint-config-prettier

With that installed, let’s go to the .eslintrc file, and add prettier at the end of your extends list to disable any other previous rules from other plugins:

// .eslintrc
{
  "parser": "@typescript-eslint/parser",
  "parserOptions": {
    "ecmaVersion": 12,
    "sourceType": "module",
  },
  "plugins": ["@typescript-eslint"],
  // HERE
  "extends": ["eslint:recommended", "plugin:@typescript-eslint/recommended", "prettier"],

  "rules": {
    "@typescript-eslint/no-unused-vars": "error",
    "@typescript-eslint/consistent-type-definitions": ["error", "type"],
  },

  "env": {
    "browser": true,
    "es2021": true
  }
}

That’s it! Now you know how to use these static testing tools effectively. It’s great to have some automation for specific tasks like linting, formatting, and type checking.

ESLint vs. Prettier

Below is a general comparison of the key differences and purposes that ESLint and Prettier serve:

	ESLint	Prettier
Nature	ESLint is a static code analysis tool and linter for JavaScript	Prettier is a code formatter, primarily focused on formatting code to make it more readable and consistent
Purpose	Code quality and bug detection	Code formatting
Configuration	Highly configurable, rules can be defined in a .eslintrc config file	Less configurable, as it enforces a specific set of rules without configuration. But you can still configure some options in a .prettierrc.json config file
Integration	Can be integrated with popular IDEs to provide realtime feedback and auto-fixing capabilities	Can be integrated with popular IDEs to format files on save to fix formatting issues

In summary, ESLint and Prettier serve distinct purposes in JavaScript development. While ESLint focuses on enforcing coding standards and patterns, detecting code quality issues, and identifying bugs, Prettier focuses on automatically formatting code to maintain consistency.

To learn more about linting in Typescript, check out this video:

Conclusion

Using TypeScript and ESLint together can boost our confidence in our code. It helps us prevent bugs and can save us time in the long run. I recommend you try using TypeScript and ESLint for an enhanced development experience, benefitting both you and your team in your upcoming projects.