The JavaScript ecosystem is changing so fast that it can be overwhelming to pick the best tools to use. To solve this problem, in this article, I’m going to walk you through how to set up a front-end project from scratch.

We'll cover things like must-have editor extensions, adding JavaScript libraries to your project, why you'll use Node.js even if you want to do front-end development, and setting up an application bundler that will generate a live preview as you code in your browser.

You can also watch this article as a video on YouTube. Let's dive in.

Table of Contents

1. How to Choose a Code Editor

2. How to Auto-format Your Code in VS Code

3. Why Do You Need Node for a Front-End Project?

4. How to Run Your Project

5. How to Add Libraries to Your JavaScript Project

6. How to Get Coding Tips While You Code

7. Initialize a Project with Vite

8. Summary

How to Choose a Code Editor

Let’s start with the foundations. As a web developer, you mostly edit text, so you need a good editor. So which one should you use?

Picking an editor is highly based on personal preference, as most editors have very similar features.

If you don’t have a personal preference, I highly recommend VS Code. Lately, it has become the de facto standard editor for web development.

One of the greatest features of all the mainstream editors is that you can add extensions to them. Let’s walk through two extensions that are must-haves.

How to Auto-format Your Code in VS Code

Prettier is an extension that makes your code more readable and more consistent.

Let’s say you copy-pasted some code, and it’s hard to read. The tabulation is off, a line is too long, and so on. Then you just save the file, and magically, everything looks as it should be.

This is what Prettier does. It formats the code based on best practices. It doesn't just fix tabulation and wrap the lines. It also adds parentheses to improve code readability, makes sure you are consistent with quotation marks, and many more.

To make it work in VS Code, we must first install the Prettier extension. To do so, go to the extensions panel in VS Code, search for Prettier, and then install it.

Installing this extension doesn't format your files automatically on save by default. The default behavior is that once you install this extension, you can right-click within a file and select Format Document. You can also select part of a file and choose Format Selection.

The first time you do this, you need to select the default formatter. VS Code already has a formatter, but it isn’t as powerful as Prettier. Now that you have two formatters, you have to let VS Code know that you want to use Prettier for formatting in the future.

If you wish to auto-format your files when you save them, you need to change the settings. Go to Settings in your VS Code preferences and search for the Format on Save option. By default, this is false, so make sure that you tick this checkbox. With this, Prettier formats your files every time you save them.

Formatting can be controversial, though. I highly recommend the default settings, especially for beginners. But if you prefer a different style, you can customize things.

You can indicate with comments to ignore specific lines and create a config file to list your preferences.

In the root folder of your project, you can create a file called .prettierrc and add a few options. A typical option could be if you prefer single quotes instead of double quotes in your files. Or if you don't want to have semi-colons at the end of your lines.

With this configuration, you will have a different format once you save your files.

{
  "singleQuote": true,
  "semi": false
}

There are many more options, of course. If you want to dig deeper, check out Prettier's documentation.

Why Do You Need Node for a Front-End Project?

Before we get to the second must-have extension, we need to set up a few other things. First, we need to talk about Node.js. What is Node, and why do you need it even if you work as a front-end developer?

Node is often associated with backend development, but that's not its only job. Node is a JavaScript runtime – this means it runs JavaScript files outside of the browser.

There are two ways of running JavaScript code. You can either have it as part of a website and run the entire website in a browser, or run only the Javascript file with a runtime like Node.

In the example below, we have a very simple Javascript file that prints "Hello World" to the console. If we have Node installed, we can go to the terminal, navigate to the folder where this file is, and then run it with Node like this. You can see that the file was executed, and the result is in the console.

That's what Node really is: a tool that runs JavaScript files on their own.

JavaScript mostly behaves the same way in both environments. But there are also differences in what JavaScript can do in a browser vs when it runs with Node.

For instance, when running in the browser, JavaScript can access and modify HTML elements. That's the main point of having JavaScript in the first place.

In Node, there's no HTML file. JavaScript runs on its own. On the other hand, in Node, JavaScript has access to your file system and can read and write your files.

For instance, you can run scripts on your machine to initialize a project. We are going to do that. You can run checks on your files and automatically correct the mistakes. Or you can run your test files.

In short, Node lets you run some tools that make your life much easier as a developer.

To install Node, go to nodejs.org and install it. If you are unsure if you already have Node, you can also go to your terminal and run node -v to check. If you get a version number, you have Node.

So, why do people associate Node primarily with backend development? If the backend code is in JavaScript, the servers must run it somehow without a browser. So yes, if you are a backend developer using JavaScript, then you're most probably going to use Node. But Node is much more than that.

How to Run Your Project

Now that we have Node, we can use a live server to see our site live in the browser as we develop it. Without this, you need to manually refresh the browser window every time you make a change.

These tools are called bundlers because they take all your files and turn them into a neat package you can run in the browser. So why do you need them?

• They update your site live in the browser with hot reloading. When you save a file, you immediately see the result in your browser.

• As web development tools have evolved, the browser won't understand your files when you use anything more advanced. For instance, are you using React? Then, you're using the JSX syntax – the one that looks like HTML. The JSX syntax is not part of JavaScript. You need a tool to convert it into plain JavaScript. Otherwise, it won't run in your browser. Or are you using TypeScript? You also need to turn that into JavaScript. Or, if you're using SCSS or any other CSS dialect, you need to convert it to plain CSS.

• If you import libraries using the JavaScript module system, you need a live server to avoid CORS issues in your browser.

This is what bundlers do. They make sure that you can use modern-day tooling while you're developing your application, and they can also create a final production build that you can publish on the internet.

How do you pick a bundler? There are several options, and essentially, they all do the same thing. The difference between them is in their performance, configuration options, and ease of use.

The most used bundler is still webpack, one of the earliest bundlers in the field. But the one that seems to have taken over the throne and gained more and more popularity is Vite. Here's a chart from the latest edition of the State of JavaScript survey.

This chart shows that while most developers have used Webpack, they don’t necessarily love it. At the same time, Vite's popularity is rising while still maintaining a positive sentiment.

If you haven't checked out the State of JavaScript survey before, I highly recommend going through it. It gives you an excellent overview of the latest trends with JavaScript. You can learn which tools and libraries people love to use and which they will abandon soon. If you feel overwhelmed by all the changes in the JavaScript ecosystem, the results of this survey can be a great guide.

Once we have a folder for our project, let's navigate to it using our terminal. The easiest way to do this is to open the folder in VS Code and then use the built-in terminal. VS Code will open the terminal with the correct folder.

Then, you can run the project in the terminal with the following command. npx is a command line tool that comes with Node. This is one of the reasons we installed Node: to be able to run commands like this.

npx vite

The first time you run this script, it will ask you to install Vite. Say yes. Then, it will show you the URL of a local server, which you can open in a browser to view your project.

  VITE v6.1.0  ready in 162 ms

  ➜  Local:   http://localhost:5173/
  ➜  Network: use --host to expose
  ➜  press h + enter to show help

Now, if you update a file and save the changes, the new version appears in the browser immediately. It generates a live preview of your site until you stop the script or close the terminal. You can keep it running while you're developing your site.

Once you have finished, you can press Ctrl+C to stop the script. If it gets desynchronized or you break it with an error, restart it by pressing Ctrl+C to stop it and rerunning the same script. So that's how you run a project with Vite.

How to Add Libraries to Your JavaScript Project

Now that we have Node, we can also use npm or Note Package Manager to add libraries to our project. npm is another tool included with Node. So how does it work?

First, I will walk you through setting things up step by step the manual way so it's clear how the different parts come together. Then, I will show you how to automate most of these steps.

Navigate to your current folder in the terminal and run the following command to initialize the project. This command initializes a package.json file with some metadata.

npm init --yes

At this point, this file is not very interesting. It contains the project name, description, version number, and so on. You can change these values.

Now, we can add libraries to our package with the npm install command. In a previous article, we used Three.js to render 3D boxes in the browser.

So, as an example, let's install Three.js. Go to your terminal again, make sure you are in the correct folder, and run the following command:

npm install three

This command will install Three.js. But how do you know that the keyword is three here, not Three.js?

When you don’t know the package name, you can just google npm and the name of the library you need. Or, if you don't even know the library name, you can also just search for an npm 3D library and see what Google comes up with.

We can go through each package one by one and pick one based on their capabilities and other info. These packages mostly come with descriptions and quick examples to give you an idea of what the library can do for you.

Another indicator you might want to look for is the weekly downloads and the date of the last update to ensure you select an actively maintained library that people still use.

Once you find the package you are looking for, you can see the command to install it at the top right corner: npm i three. The i here is just shorthand for install. Another way to learn how to install Three.js is to go to its official documentation and check the installation guide.

When we install a package, three things happen:

• It adds the latest version of Three.js in our package.json file as a project dependency.

• It also creates a package-lock file, which NPM uses to keep track of the dependencies. You should never edit the dependency section of your package.json file or the package-lock file manually. Instead, you should always use commands like npm install and uninstall to add, remove, or update packages.

• Finally, the node_modules folder gets created. This folder contains the source code of Three.js. When we import Three.js in our project, it looks for it in this folder. The content of this folder is also something that you should never change. You can look into it if you're interested in the source code of the library that you're using, but you shouldn't change it.

If something goes wrong and you have an error with your dependencies that you can't figure out, then you can always safely delete the node_modules folder and the package-lock file and reinstall your dependencies based on the package.json file. This is not something that you should do, but you can always go back to having a clean slate.

Now that we have installed Three.js, we can create a simple website that displays a 3D box. It's a simple HTML file and a JavaScript file with the code for the 3D box. The key here is that we import Three.js with the import statement in the JavaScript file. This import will use the package that we just installed.

Then, we can run the project with Vite. Using imports means that we use the module system now. Running a project with the module syntax can be a bit tricky, as the browser gives you CORS errors by default. However, as we are using Vite to run our project, it works seamlessly without any questions. That’s one of the reasons we use Vite.

If you want to learn more about building 3D games with Three.js, check out my earlier article on building a minimalistic car in the browser.

How to Get Coding Tips While You Code

The second must-have editor extension is ESLint. While Prettier formatted the code, ESLint gives you coding tips.

It helps you catch basic mistakes and avoid patterns that can cause bugs or be misleading when you try to understand the code.

Here’s a simple example where you declare a variable, but then you have a typo, and you try to use another variable that doesn't exist. ESLint will highlight this for you. It will give you an error both at the variable declaration, saying that you created a variable you don't use, and add the usage, saying that you're trying to use a variable that is not declared. With ESLint, it's easy to spot that you made a typo.

ESLint, of course, is much more complex than just being able to catch simple errors. There are also less obvious use cases where you might not understand why ESLint is complaining. Then, you can always click the link in the error popup for more details explaining why this pattern is harmful and what you can do to avoid it.

So how can we use ESLint in our projects? This time, we need to have an extension and a configuration. First, as we did with Prettier, we must install the ESLint extension. Go to your extensions, search for ESLint, and install it.

We also need to set up ESLint for our project. Before we do that, we need to make sure that the project already has a package.json file. If you don't already have a package.json file, we first have to run npm init --yes to initialize the project. Then, we can generate an ESLint config with the following command:

npm init @eslint/config@latest

This script will ask you a few questions. Based on your answers, it will customize the configuration and the rules to check. For most cases, you can use the default option.

• The first time, it will ask for permission to install ESLint. Say yes.

• Then, it will ask you whether to use ESLint only for syntax checks or to find problems as well. Choose the second option to get the most help from ESLint.

• Then select that you’ll use it with JavaScript modules. Modern web development projects use the JavaScript module system. We use JavaScript modules if we have imports and exports in our code.

• Then, it will ask what framework we are using. If we select a framework, it will add framework-specific rules to our project. For instance, using it with React will force us to define the prop types. If we don't use a front-end framework, just vanilla JavaScript, then select "None of these".

• Then, it will ask if the project is using TypeScript. Choose based on your preference.

• It asks where you run the code. As we have a front-end project, select "Browser".

• Then, it will ask if you want to install the additional dependencies that are required for the rules based on your selections. Select yes.

• It will also ask what package manager we’re using. We haven't talked a lot about this, but there are multiple package managers that we can use. Select the default: npm.

These were a lot of questions. Let's see what happened after we ran this command.

After this step, we have ESLint and some other dependencies based on the answers in the package.json file as development dependencies. Development dependency means that ESLint won't be part of your website's final code, but we need it during development.

ESLint also became part of our node_modules folder, and there are many more packages here now. This is because a dependency can have other dependencies, and the dependencies of the dependencies will also be part of the node_modules folder.

ESLint also created a config file that sets up the rules based on your answers. We will see how to customize the rules.

Now that ESLint is working, you should also see errors in the code once something is off. If you go to your JavaScript file and try to use an undeclared variable, ESLint will highlight the issue.

ESLint is also highly customizable. For instance, we might not want to mark an unused variable as an error. First, we go to the error popup and select the identifier of this type of error. Then, we go to the ESLint config and override this error as follows. Here, we can reduce the severity to a warning or completely turn off this rule.

import globals from "globals";
import pluginJs from "@eslint/js";


/** @type {import('eslint').Linter.Config[]} */
export default [
  {languageOptions: { globals: globals.browser }},
  pluginJs.configs.recommended,
  {
    rules: {
      "no-unused-vars": "off", // Turn off the No Unused Variables rule
    }
  }
];

But if you're a beginner, I recommend following the rules that ESLint has by default. Sometimes, it might be annoying to fix all the seemingly harmless issues, but all these rules are based on industry best practices, so it's good to follow them. For more details, check out ESLint's documentation.

Initialize a Project with Vite

We walked through the step-by-step process of setting up a project. We used npm init to initialize the project, manually set up ESLint, and ran our project with Vite. Vite can also initialize the project with a sample application and all the necessary files, which is especially handy when we set up a React project.

Let's see how to set up a vanilla JavaScript and a React project. Let's navigate to a folder in the terminal that will contain our project. We don't need to create a project folder this time because the script will make it for us. Then, run the following command to initialize a project:

npm create vite@latest

This command asks you a few questions.

• First, it will ask you for the project name, which will also be the name of the folder created as the project root.

• Then, it will ask what framework you use. If you don't use any framework and want plain old JavaScript, choose "Vanilla." If you use React, choose React.

• Then, it will ask you if you want to use TypeScript or JavaScript. Here, the default is TypeScript. If you're a beginner in web development, choose JavaScript. If you are more confident with your skills, then go with TypeScript. TypeScript is more complicated, but it has become the industry standard in web development, and most jobs require you to know it. As a beginner, you can go with JavaScript.

Now, we can navigate to the new folder created and check out what we have here. If you choose a vanilla JavaScript project, you can see it generated a simple application with HTML, CSS, and some JavaScript files. You can change or even delete these. You'll need an HTML file as an entry point, but you can replace the rest.

We can run this project with npx vite as we did before, but there’s a better way. For a real project, we want to add Vite as a development dependency to ensure consistency with the version we are using.

{
  "name": "my-project",
  "private": true,
  "version": "0.0.0",
  "type": "module",
  "scripts": {
    "dev": "vite",
    "build": "vite build",
    "preview": "vite preview"
  },
  "devDependencies": {
    "vite": "^6.1.0"
  }
}

The package.json file shows that Vite has been added as a development dependency. To use this hardcoded version, we first have to install it via npm install. This command installs all the dependencies listed in the package.json file.

npm install

This package.json file now also has a scripts section. This section can define scripts to run your app locally, create a production build, or test your application. You can run them with npm run. So, for instance, to run the application, you can open the terminal with the correct folder and run the following command.

npm run dev

This runs the script labeled as “dev” in the scripts section, which will run the Vite version we just installed with npm install.

Vite does not install ESLint when you create a vanilla project, but you can always install it manually, as we did before with npm init @eslint/config@latest.

If you choose React as a framework when we initialize the project, we will have a couple more files. For instance, we have an ESLint config with the recommended React settings. We also have a Vite config that enables us to use React and a sample application that we can run.

To run this app, we need to install the dependencies. So, let's go to the terminal and run npm install. This will install all the dependencies, including React. Then, we can run this app with npm run dev, and we will have a working React application.

Summary

In this article, we set up and run a front-end project with Vite. We also covered how to find and add dependencies, how to have consistent and automatic formatting with Prettier, and how to avoid bugs with ESLint.

What happens once you finish developing your app? How do you upload it to the web and share it with the world? That's the topic of a future article.

Subscribe for more tutorials on Web Development:

Even for TypeScript, which is a strongly typed language whose compiler does a great job of detecting errors at compile time, linters such as ESLint have plugins that catch problems which are not caught by the compiler.

When you generate a new app using the Next.js CLI (npx create-next-app), ESLint is configured by default. But there are several problems with the linting setup generated by create-next-app:

• If you choose SCSS for styling, you should use Stylelint in the build process to lint CSS or SCSS stylesheets. But it’s not set up automatically.

• If instead you opt for Tailwind for styling, you should set up the Tailwind plugin for ESLint. But again, this isn’t done in the generated ESLint configuration.

• If you choose TypeScript, then in Next.js v14 and below, TypeScript-specific ESLint rules are not configured, contrary to what the documentation states. While a Next.js v15 app has these set up, I would still tweak the setup further with the more powerful linting rules provided by the typescript-eslint project. These include the no-floating-promises rule which points out if you have forgotten to await a method that returns a Promise. These and other rules from typescript-eslint are going to save you lots and lots of times as you write TypeScript code.

• And finally, Prettier is not set up. Prettier is a code formatting tool. It can prevent inconsistently formatted code from getting into the code repository, which would make comparisons between different versions of the same file difficult. Also, nicely formatted code is easier to work with. So this is a pretty big omission.

In this tutorial, I'll show you how I set up linting and formatting in my Next.js projects in a way that addresses the issues above. I’ll also teach you how to install and configure some related VS Code extensions for coding assistance.

To follow along, you can either use a Next.js project you already have, or generate a new app by running npx create-next-app on the terminal.

If you’re scaffolding a new app, your choices are up to you (defaults are fine) but make sure to choose YES in response to the question about whether you’d like to use ESLint:

If you are following along with an existing app rather than a new one, upgrade it by running the following command in app root:

npm i next@latest react@latest react-dom@latest eslint-config-next@latest
npm i --save-dev eslint

This will avoid versioning conflicts down the line.

If you cannot upgrade to the latest version, you’ll need to specify versions for packages that will be installed in this tutorial to get around any version conflicts. Be warned that this can be frustrating.

Now you’re ready to open up the app in your code editor and proceed as follows.

MONOREPO NOTE: A monorepo is a Git repository that contains multiple projects, each in its own subfolder. For example this repo is for a full-stack solution that contains two projects: a Next.js app in folder flowmazonfrontend and a .NET Core API project in folder flowmazonbackend:

If your Next.js app is contained in a monorepo that contains both a Next.js app and other projects, I recommend that you do all of the setup below within the Next.js app's folder. This is the folder you should open in your code editor and cd into on the terminal. There is one bit of setup (lint-staged and Husky) that will need to be done in the monorepo root folder. I shall point it out in due course.

Prerequisites

For this tutorial, I assume that you know how to:

• write a basic Next.js app with two or more pages.

• install additional NPM packages into your app

Table of Contents

• Introduction

• Prerequisites

• Table of Contents

• Set Up Prettier

  • A note on line endings in Prettier

• Set Up ESLint

  • Basics of ESLint configuration

  • ESLint Setup for TypeScript

  • ESLint Setup for Tailwind

  • ESLint Setup for Prettier

• Set Up Stylelint

• Set Up package.json Scripts

• Set Up lint-staged

• Set UP VS Code Extensions

• Final Checks and Troubleshooting

• Conclusion

Set Up Prettier

Prettier is an opinionated code formatter that can format pretty much any file (.html, .json, .js, .ts, .css, .scss and so on).

Set it up in yuor app as follows:

1. Install Prettier:

    npm install --save-dev prettier
   

2. If you chose Tailwind for styling when generating the app, then install prettier-plugin-tailwindcss:

      npm install --save-dev prettier-plugin-tailwindcss
   

   This package is a Prettier plugin and provides rules for reordering of Tailwind classes used in a class or className attribute according to a canonical ordering. It helps keep the ordering of Tailwind classes used in the markup consistent.

   %[https://youtu.be/tQkBJXwzY8A?autoplay=1]

3. Create .prettierrc.json in youyr project root. If you’re using SCSS for styling, paste the following snippet into this file:

    {
      "singleQuote": true,
      "jsxSingleQuote": true
    }
   

   If you’re using Tailwind instead, paste the following into .prettierrc.json:

    {
      "plugins": ["prettier-plugin-tailwindcss"],
      "singleQuote": true,
      "jsxSingleQuote": true
    }
   

4. Create .prettierignore file in the app root, with the following content:

    node_modules
    .next
    .husky
    coverage
    .prettierignore
    .stylelintignore
    .eslintignore
    stories
    storybook-static
    *.log
    playwright-report
    .nyc_output
    test-results
    junit.xml
    docs
   

   This file ensure that files which are not app code (that is, those which are not .js, .ts, .css files and so on.) do not get formatted. Otherwise Prettier will end up spending too much time processing files whose formatting you don't really care about.

   'prettierignore (the file we just created), .eslintignore, and .stylelintignore have been ignored because these are plain text files with no structure so Prettier would complain that it cannot format them.

5. Finally, I recommend that you follow the steps in this post to set LF as the EOL character, both in the repo and in your VS Code settings. Reasoning for this is given in the following subsection.

A note on line endings in Prettier

Prettier defaults to LF (Line Feed character) for line endings. This means that when it formats files, it will change all occurrences of the CRLF character sequence, if any, to LF.

LF is also the default in text editors and other tools in Unix-based systems (Linux, MacOS etc.). But on Windows, the default for line endings is CRLF (Carriage Return character, followed immediately by Line Feed character).

Windows tooling such as text and code editors can easily handle LF as line ending. But CRLF can be problematic for tools on Unix-based systems such as Linux and various flavours of Unix. Therefore it makes sense to only use LF as line endings in code as this would work on both Windows and Unix-based systems.

Configuring LF as the EOF character in Git repo and in code editors will bring your tooling in line with Prettier's default. It will also ensure that all files in the Git repo consistently have LF line endings. Thus if a contributor to your repo is on Windows which uses CRLF as EOL character, the code they add or modify in the repo would still use LF: the code editor would default new code files to LF; git commit` would convert any CRLFs to LF when committing.

Finally, setting LF as the line endings for the whole repo would avoid strange things that happen when on Windows, Prettier retains its default of LF but Git and your code editor continue to use their default of CRLF for line endings:

• When VS Code Prettier extension formats a file (for example, when the extension is set up to "autoformat on save"), it does not change CRLF line endings. But formatting the same file by running Prettier on the command line does change line endings to LF. This discrepancy can be annoying.

• Git may show warnings like this when when you run git add .:

  

Set Up ESLint

Basics of ESLint configuration

ESLint comes with a number of linting rules out of the box. But you can also supplement these with ESLint plugins.

An ESLint plugin defines some linting rules. For example, if you look in the GitHub repo for Next's ESLint plugin, eslint-plugin-next, each file in the src/rules folder defines a linting rule as a TypeScript function. The index.js of the package then exports these rule functions in the rules object in its default export:

module.exports = {
  rules: {
    'google-font-display': require('./rules/google-font-display'),
    'google-font-preconnect': require('./rules/google-font-preconnect'),
    'inline-script-id': require('./rules/inline-script-id'),
    ...

The basic way to use these rules in your app is to install the plugin package, then reference it in the ESLint configuration file in the app's root folder.

For example, we can use rules from the eslint-plugin-next mentioned above by running npm install --save-dev eslint-plugin-next, then placing the following content in the ESLint config file .eslintrc.json in the app root:

{
    plugins: ["next"],
    "rules": {
        "google-font-display": "warning",
        "google-font-preconnect": "warning",
        "inline-script-id": "error",
    }
}

If you now run npx eslint . in your app's root folder, ESLint will lint every JavaScript file in the app against each of the three rules configured above.

There are three severities you can assign to a rule when configuring it for use: off, warning and error. As the snippet above shows, you enable a rule by assigning to it a severity of warning or error in the app's .eslintrc.json.

When referencing a plugin in your app's ESLint configuration file, the prefix eslint-plugin- in the plugin's package name is omitted. This is why the package that contains linting rules for Next.js, eslint-plugin-next, is referenced only as "next" in the snippet above.

Since it is quite cumbersome to configure a severity level - off, warning or error - for every single rule from every plugin that you want to use, the norm is to reference an ESLint sharable config , or config for short, that is exported by an NPM package. This is a JavaScript object that declares plugins and configures rules from these with severity levels just as we did above.

For example, the default export from eslint-plugin-next also contains several ESLint configs. Here is a another snippet from index.js of the plugin, this time showing exported ESLint configs in addition to the rules object for exporting rule functions:

module.exports = {
  rules: {
    'google-font-display': require('./rules/google-font-display'),
    'google-font-preconnect': require('./rules/google-font-preconnect'),
    'inline-script-id': require('./rules/inline-script-id'),
    ...
},    
configs: {
    recommended: {
      plugins: ['@next/next'],
      rules: {
        // warnings
        '@next/next/google-font-display': 'warn',
        '@next/next/google-font-preconnect': 'warn',
        ...

        // errors
        '@next/next/inline-script-id': 'error',
        '@next/next/no-assign-module-variable': 'error'
        ...

      }
    },
    'core-web-vitals': {
      plugins: ['@next/next'],
      extends: ['plugin:@next/next/recommended'],
      rules: {
        '@next/next/no-html-link-for-pages': 'error',
        '@next/next/no-sync-scripts': 'error',
      },
    },
}

As you can see, in addition to the rules (there are many more than those shown above), the plugin also exports two configs - recommended and core-web-vitals - that enable different selections of the rules defined in the plugin by assigning severity levels of error or warning to them.

The config that is normally used in Next.js projects is core-web-vitals. We can use this config object in our app’s ESLint configuration file (.eslintrc.json in app root) as follows:

{
  "extends": ["plugin:next/core-web-vitals"]
}

Thus is much simpler than declaring the plugin in plugins object and then assigning a severity level of error or warning to each rule from the plugin that we want to use.

Note the difference between Configuration File – this is the ESLint configuration file named .eslintrc.json - and Shareable Config (or config for short) – this is an object that configures some rules from an ESLint plugin for use in a client project by assigning severities to selected rules.

Contents of the configuration file are themselves a config. But in configuration files, we do not typically import a plugin and configure all rules from it that we want to use. Instead we almost always import a well-known/trusted config object that is exported by an NPM package. Such a config object - one that is exported by an NPM package for use in ESLint configuration files (in other packages/apps) - is also known as a shareable config.

Typically, plugins - these define ESLint rules as JavaScript/TypeScript functions - also bundle their rules into one or more shareable configs. The recommended config from plugin eslint-plugin-next that we used above is just one such config.

Shareable configs do not only come from plugin packages, although it is customary for plugins to also export one or more shareable configs composed of their own rules. Other packages, whose names begin with eslint-config- (as opposed to eslint-plugin-) can provide one or more named configs.

Next.js provides one such package named eslint-config-next. This re-exports configs recommended and core-web-vitals from the plugin. It also re-exports (in v15 and above of the package) a config of TypeScript linting rules from plugin typescript-eslint/eslint-plugin. So instead of using recommended config from the plugin like we have done above:

{
  "extends": ["plugin:next/core-web-vitals"]
}

we could have installed the package eslint-config-next and used that in .eslintrc.json:

{
  "extends": ["next/core-web-vitals"]
}

Since the package's name is not prefixed with plugin:, ESLint considers it to be a config package, reconstructing the name as eslint-config-next rather than as eslint-plugin-next. Notice how with config packages also, we delete the canonical prefix eslint-config- when referencing it in the ESLint configuration file.

NOTE: In order to reference a shareable config provided by a package that only provides such configs but does not define or export linting rules, such as eslint-config-next, all you need to do is install the package and add the shareable config to "extends" in your .eslintrc.js. This is shown in the snippet above.

But if you want to reference a shareable config from an ESLint plugin, for example the package eslint-plugin-storybook which exports a shareable config named recommended, but you do NOT want to configure individual rules exported by the plugin, then I am not sure whether you need to declare the package in "plugins" array in your .eslintrc.js or not. I would declare it in "plugins" anyway as it may actually be necessary but wouldn't do any harm if it's not. Almost every ESLint example that I have come across, such as this one, does the same.

For example, if I want to use shareable config recommended from plugin eslint-plugin-storybook, and even though I would not be configuring any individual linting rules provided by this plugin, I would both reference the config in "extends" and, just to be safe, declare the plugin itself in "plugins" (after installing the plugin via command npm install -D eslint-plugin-storybook):

{
    "plugins": ["storybook"],
    "extends: ["plugin:storybook/recommended",]
}

It is possible to reference multiple shareable configs in extends. In this case, all the rules from all configs are used - except where there are multiple configs that each provide a rule with the same name. In this case the last config, proceeding left to right, wins. This is to say where there is a naming conflict, ESLint will use the rule from the last config on the list.

It is possible to use ESLint configuration file formats other than JSON. You can provide the same information as in an .eslintrc.json file in a JavaScript (.eslintrc.js or .eslintrc.cjs) or yaml (.eslintrc.yml or .eslintrc.yaml) file instead.

Also, ESLint has a new configuration file format often called flat config (which I haven't used here) where the config files are either JavaScript or TypeScript files.

Armed with an understanding of how to configure ESLint for use, you are ready to set up ESLint in your Next.js project. The sections below shows you how to do this.

ESLint Setup for TypeScript

If your app uses TypeScript, modify the ESLint configuration file (.esilntrc.json) as follows:

1. On the terminal, in app's root folder, run the following command:

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

   @typescript-eslint/eslint-plugin provides a number of linting rules for TypeScript files, as well as shareable configs, that augment the checking that the TypeScript compiler does.

   @typescript-eslint/parser is a parser that allows ESLint to parse TypeScript files (by default it can only parser JavaScript files).

   I am adding TypeScript compiler as a package - typescript - because typescript-eslint Getting Started instructions do the same.

2. In app root folder, rename .eslintrc.json to .eslintrc.js. Then Replace contents of .eslintrc.js in app root with the following:

    /* eslint-env node */
    module.exports = {
      root: true,
      extends: [
        'next/core-web-vitals',
      ],
      plugins: ['@typescript-eslint', 'tailwindcss'],
      parser: '@typescript-eslint/parser',
      overrides: [
        {
          files: ['*.ts', '*.tsx'],
          parserOptions: {
            project: ['./tsconfig.json'],
            projectService: true,
            tsconfigRootDir: __dirname,
          },
          extends: [
            'next/core-web-vitals',
            'plugin:@typescript-eslint/recommended',
            //'plugin:@typescript-eslint/recommended-type-checked',
            // 'plugin:@typescript-eslint/strict-type-checked',
            // 'plugin:@typescript-eslint/stylistic-type-checked',
          ]
        },
      ],
    };
   

   This is what the various lines of this file do:

   /* eslint-env node */ stops ESLint from complaining that this is a CommonJS module. We have had to put this in because ESLint, as we have configured it here, does not allow CommonJS modules (which .eslintrc.js is, see module.exports = ... at the top) and expects modules in the project to be ES6.

   root: true says this is the topmost ESLint configuration file even though there may be nested ESLint configs in subfolders.

   extends: specifies various ESLint configs, each of which enables a collection of linting rules.

   'next/core-web-vitals' is a config provided by eslint-config-next that bundles Next.js-specific rules (both for JavaScript and TypeScript, from an inspection of its code on GitHub).

   The recommended-type-checked config (used in a nested extends within overrides object - this is explained shortly) is provided by @typescript-eslint/eslint-plugin. This plugin is part of the typescript-eslint project that publishes packages for linting rules and parsers to support linting of TypeScript files by ESLint.

   The configs used is described here. It is a superset of the non-type checked versions of the config, recommended. It adds linting rules which use TypeScript's type checking API for additional type information. These rules are more powerful than those contained in the base, non-type-checked recommended config that only rely on the ESLint parser for TypeScript - package @typescript-eslint/parser.

   You might prefer to use the strict-type-checked and stylistic-type-checked configs, also provided by @typescript-eslint/eslint-plugin. These are stricter than what I have used.

   The least strict choice for TypeScript linting would probably be the recommended config. This is what is re-exported by eslint-plugin-next as config named typescript and is referenced in Next.js instructions for setting up ESLint with TypeScript as next/typescript (at least as of the time of this writing, September 2024). I prefer the config I have used instead.

   parser: '@typescript-eslint/parser' specifies the ESLint TypeScript parser to be used instead of the default Espree parser which cannot parser TypeScript files.

   parserOptions: tells the parser where to find the tsconfig.json file. This information allows the rules in the type-checked config used above - recommended-type-checked - to use TypeScript type checking APIs.

   If we were using non-type-checked rules contained in other configs exported by the plugin, such as the recommended config, we would not need to provide this information.

   plugins: ['@typescript-eslint'] : I don't know what the purpose of this line is. It shouldn't be necessary and I have tested that the given ESLint configuration works fine without it. But it doesn't do any harm and was contained in an example in the plugin's documentation from which I adapted the above config. So I have kept it.

   The overrides section ensures that the TypeScript parser options that we’ve had to configure in order to support type-checked configs apply only to .ts and .tsx extensions (from this excellent StackOverflow answer). Otherwise, if parser and parserOptions objects had been at the top level, then running ESLint on the project would throw errors on .js files.

   This is a problem as we have several .js config files including the .eslintrc.js itself, so there will be linting errors. We can avoid these errors by using the override.

ESLint Setup for Tailwind

If your app uses Tailwind, modify the config as follows:

1. On the terminal, in app's root folder, run npm install --save-dev eslint-plugin-tailwindcss

2. In ESLint config, add "plugin:tailwindcss/recommended" to the END of extends:

    {
      "extends": ["next/core-web-vitals", ..., "plugin:tailwindcss/recommended"],
   
    }
   

3. In the ESLint config, add "tailwindcss" to plugins and add a rules object as shown below:

    {
      "plugins": [..., "tailwindcss"],
      "rules": {
        "tailwindcss/classnames-order": "off"
      },          
    }
   

4. If your app uses TYPESCRIPT, then also add "plugin:tailwindcss/recommended" to inner extends inside overrides and duplicate the rules object inside overrides:

      {
        ...
        overrides: [
        {
           extends: ["next/core-web-vitals", ..., "plugin:tailwindcss/recommended"],
           rules: {
             'tailwindcss/classnames-order': 'off',
           },
        }
      }
   

In the Tailwind setup steps above, we have installed the package for the ESLint plugin for Tailwind, eslint-plugin-tailwindcss, and used the config recommended provided by the plugin.

eslint-plugin-tailwind provides some useful linting rules for Tailwind CSS classes used in HTML or JSX/TSX markup. The biggest one for me is that if a class used in code is not a Tailwind class, there would be a linting error. This makes sense as when I am using Tailwind, I only use Tailwind-generated classes and do not define my own CSS classes.

The plugin also has a rule that checks that the sequence of Tailwind class names used in the class or className attribute in markup follows a canonical ordering. But we installed prettier-plugin-tailwindcss in our Prettier configuration above which also reorders Tailwind class names. So we don’t need this rule in ESLint and it might conflict with what Prettier does in our workflow.

We’ll turn this rule off, which is named tailwindcss/classnames-order, in the configuration above by declaring the plugin in plugins object, then setting the rule to off in the rules object.

ESLint Setup for Prettier

1. On the terminal run:

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

2. In ESLint config, add "prettier" to the END of extends:

    {
      "extends": ["next/core-web-vitals", ..., "prettier"]          
    }
   

3. If your app uses TypeScript, then also add "plugin:tailwindcss/recommended" to the inner extends inside overrides also:

     {
       ...
       overrides: [
       {
          "extends": ["next/core-web-vitals", ..., "prettier"],
       }
     }
   

   In the Prettier setup steps above, the config referenced as prettier is the name of the NPM package eslint-config-prettier with eslint-config- deleted. The default export from the package is an entire ESLint config object and this is the config we want to use.

   So in this case, we do not suffix the name prettier with /<name of config> as we have done when referencing the named config core-web-vitals from package eslint-config-next when we referenced is as next/core-web-vitals (see step 1 above).

   This config switches off those rules in ESLint that conflict with the code formatting done by Prettier. This should be the last config in extends.

4. Create .eslintignore in the project root. It doesn't need to have any content for now, but will come in handy in the future if ever you need to add folders or files that should be ignored by ESLint (see the final section of this post for an example).

Set Up Stylelint

Stylelint is a linter for CSS and SCSS stylesheets.

If you are using SCSS and NOT Tailwind, then set up Stylelint by following the instructions below. This set up will work for both CSS and SCSS files:

1. On the terminal in project root run this command:

    npm install --save-dev sass
   

   Next.js has built-in SASS/SCSS support (so the Webpack config knows how to handle .scss and .sass files). But you still need to install a version of the sass package yourself, which is what we did above.

2. Next, install packages for Stylelint and its rule configs:

    npm install --save-dev stylelint stylelint-config-standard-scss stylelint-config-prettier-scss
   

   Of these three packages:

   • stylelint is the linter.

   • stylelint-config-standard-scss is a Stylelint config that provides linting rules. It uses the Stylelint plugin stylelint-css and extends configs stylelint-config-standard which defines rules for vanilla CSS, and stylelint-config-recommended-scss which defines SCSS specific rules. As a result, extending from this one config is enough to get linting support for both CSS and SCSS files.

   • stylelint-config-prettier-scss extends stylelint-config-prettier and turns off those Stylint rules that conflict with Prettier's code formatting. This should be declared last in extends: array in .stylelintrc.json (as shown below).

3. Now, create .stylelintrc.json in project root with the following contents:

    {
      "extends": [
        "stylelint-config-standard-scss",
        "stylelint-config-prettier-scss"
      ],
      "rules": {
        "selector-class-pattern": null
      }
    }
   

   The "extends" section declares the two Stylelint configs whose NPM packages we installed in the previous step.

   The "rules" section is used to configure stylints rules. Here you can turn on or off, or configure the behavior of, individual Stylelint rules.

   You can turn off a rule by setting it to null, as I have done for "selector-class-pattern". I turned it off because it insists on having CSS classes in the so called kebab case (for example, .panel-quiz instead of .panelQuiz). I find it inconvenient for various reasons so I turned it off.

4. Next, create .stylelintignore in the project root with the following contents:

    styles/globals.css
    styles/Home.module.css
    coverage
   

   I created this file so that the two stylesheets generated by the Next.js CLI which do not comply with the linting rules can get ignored (there might be a better way of doing this but this works for me). Also, files in coverage folder do not need to be linted and would likely throw up errors.

Set Up package.json Scripts

1. The most important script is "build". The default command for this script, next build, runs ESLint but not Prettier or (if you are using SCSS) Stylelint. So modify it in package.json file as follows:

   If your app uses Tailwind, then:

    {
      "scripts": {
        "build": "prettier --check . && next build",
        ...
   

   Otherwise, if your app uses SCSS, then:

    {
      "scripts": {
        "build": "prettier --check . && stylelint --allow-empty-input \"**/*.{css,scss}\" && next build",
        ...
   

   With this tweak to the existing build script, we can run npm run build either locally or in a CI/CD pipeline and it will fail not only on ESLint failure (this was the case before) but also on Prettier formatting or Stylelint failure.

   Indeed if you deploy your app to Vercel, the default pipeline there also calls npm run build. So when I introduced an error in one of my stylesheets, then deployed to Vercel, I got the following Stylelint error during deployment:

   

   Note that I used the --check flag with prettier in the script (that is, I used the command prettier --check .). This runs Prettier in check mode, so it only checks for correct formatting and does not change the formatting.

   I did this because the build script is what Vercel's deployment pipeline calls by default to build the code, and I don't want formatting to change during a CI build (nor do I want to tinker with Vercel defaults unless I absolutely have to).

   To run Prettier locally to actually format the codebase, I define a separate build:local script which is same as build but runs Prettier without the --check flag, as well as a separate format script just to format with Prettier (but not build). These are set up below.

2. Set up the "format" script in your package.json. This formats the codebase with Prettier and comes in handy every now and then:

    {
      "scripts": {
        ...
        "format": "prettier --write ."
   

3. I recommend setting up a build:local script as follows:

   If your app uses Tailwind, then:

    "build:local": "prettier --write . && next build"
   

   Otherwise, if your app uses SCSS, then:

    "build:local": "prettier --write . && stylelint --allow-empty-input \"**/*.{css,scss}\" && next build"
   

   Since we cannot format the code with Prettier prior to executing next build in the existing build script (for reasons described above), we can use this script locally to format code then lint and build in one go.

Set Up lint-staged

lint-staged is a package that you can use to run formatting and linting commands on staged files in a Git repo. Staged files are those that have been added to the Git index using git add .. These are the files that have changed since the last commit and will get committed when you next run git commit.

Husky is the typical choice in Node.js packages for registering commands to run in Git hooks. For example, registering the command npx lint-staged with Husky to run in the Git pre-commit hook means lint-staged will run automatically whenever you execute git commit.

At that time, the formatter (Prettier) and linters (ESLint or Stylelint) that have been configured to run in the lint-staged configuration file will run on the staged files. If there are any errors during formatting checks or linting, the commit will fail.

Whenever git commit fails due to linting errors, we can fix those, then run git add . and git commit again. Thus code only ever gets into the repo after it has been consistently formatted and verified to be free of linting errors. This is particularly advantageous in a team setting.

I prefer to only run prettier --check . on staged files. In particular, I do not change formatting of staged files and do not lint during a commit, for the following reasons:

Reason for not formatting code: I almost always build and test my code before committing. Any code formatting should have happened prior to or during this local build and test.

I find the idea that code going into my repo should change automatically just as it is being committed after I have ascertained that any code changes are good to go, a little bit unappealing.

Reason for not linting code: With TypeScript code, the compiler can catch a huge number of issues in code. The additional linting rules provided by eslint-typescript/eslint-plugin only supplement the checks made by the TypeScript compiler. So if I am linting code in staged files at commit time, I should build as well (so that the TypeScript compiler runs).

But building can be very time consuming on a large codebase. Besides, I almost always build and test before committing. Doing so implicitly runs linting (next build runs ESLint and my build scripts in package.json, as set up above, run any other linting that is necessary e.g. StyleLint). So I don’t feel the need to repeat lint or build on staged files via lint-staged.

Any lint- or build errors that might occasionally slip through into the Git repo would be pointed out when my Continuous Delivery pipeline builds the codebase (let's say in GitHub Actions on in Vercel's build pipeline). I can fix them then, in the pull request, before merge to main.

So, my personal preference is only to check for formatting on staged files, and neither reformat nor lint the code. This prevents inconsistently formatted code from getting into the Git repo where inconsistent formatting would make comparisons between different versions of the same file difficult.

So now, set up lint-staged and Husky as follows:

Note: These tools need to be set up in the root of the Git repo. If you have a monorepo that contains multiple projects, including the Next.js app in which you performed the setup above, then open the root folder of this monorepo in your code editor and also cd into it on the terminal. Otherwise stay in the folder of your Next.js app.

1. If you have a monorepo and its root folder does NOT have a package.json file, initialize an NPM package in the root:

    npm init -y
   

2. Install the lint-staged package:

    npm install --save-dev lint-staged
   

3. Create a file named lint-staged.config.js with the following contents:

    /* eslint-env node */
    const path = require('path');
    const formatCommand = 'prettier . --check';
   
    module.exports = {
      '*': formatCommand,
    };
   

4. If you are in a monorepo, the lint-staged.config.js created above needs needs to be tweaked because in this, Prettier would be invoked from multi-repo root but the files it needs to format, as well as its config file (.prettierrc.json) and its ignore file (.prettierignore), are all in the subfolder that contains the Next.js app. Do the following:

   • npm install --save-dev prettier prettier-plugin-tailwindcss

   • Replace the contents of lint-staged.config.js with the following. Make sure to substitute <Next.js app subfolder> with the actual name of your Next.js app folder:

       /* eslint-env node */
       const path = require("path");
       const formatCommand =
         "prettier --check --config ./<Next.js app subfolder>/.prettierrc.json --ignore-path ./<Next.js app subfolder>/.prettierignore";
     
       module.exports = {
         "./<Next.js app subfolder>/**/*": formatCommand,
       };
     

5. Install the Husky NPM package.

    npm install --save-dev husky
   

6. Run the following on the terminal in app root to configure Husky to run lint-staged whenever git commit runs (in Git's pre-commit hook):

    npx husky init
    echo "npx lint-staged" > .husky/pre-commit
   

   You should now have a file .husy/pre-commit in your app's folder (or in your monorepo root folder, if you're working in a monorepo) with only one line: npx lint-staged.

Set Up VS Code Extensions

If you use VS Code as your code editor, you can install the following VS Code extensions to provide linting and formatting on file save and syntax highlight on linting errors:

• ESLint extension

• Prettier extension

• Stylelint extension (if you're using SCSS and not Tailwind)

• TaliwindCSS extension (if you are using Tailwind and not SCSS)

Put the following in a settings.json file in the .vscode folder in the project (you can of course put these settings in you User Preferences file also. You can access it from Command Palette Ctrl + P).

{
  "[javascript]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  "[typescript]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  "[typescriptreact]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  "[javascriptreact]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  "[scss]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  "stylelint.validate": ["css", "scss"],
  "editor.formatOnSave": true,
  "eslint.useFlatConfig": false
}

As they’re set up, the extensions will lint and format on Save.

"eslint.useFlatConfig": false ensures that the ESLint extension is able to pick up your .eslintrc.js and doesn't look for eslint.config.js which is the filename for a config file in ESLint's new flat config format that I have NOT used in this post.

If you encounter any problems in getting the ESLint extension to work, turn on the extension's debug output by adding line "eslint.debug": true to the end of the .vscode/settings.json you just created. Then restart VS Code and look at ESLint extension's output in the OUTPUT window:

Final Checks and Troubleshooting

Now it’s time to build and commit:

npm run format
npm run build
git add .
git commit -m "fix: set up linting and formatting"

Building and committing is a good sanity check for the setup we just did.

If anything had not been set up correctly, you might get errors either during build or at commit.

If you already had some code in the project, then there might be a few errors when you commit. Typically, these can be resolved by:

• Adding folders or files to one of the *ignore files. For example, I already had some code in my project with Storybook installed. So I had to add folders .storybook and storybook-static to each of .stylelintignore, .eslintignore and .prettierignore as all three tools complained about them.

    stories
    storybook-static
  

• If Prettier complains (shows a [warn] or [error] on the terminal) about some files not being formatted properly, you either need to add them to .prettierignore or format them by running npm run format in the folder of your Next.js app.

  

• Adding plugins for specific file types. For example, I had Gherkin .feature files in my project to describe integration tests. Prettier couldn't format these. So I added the prettier-plugin-gherkin by simply running:

    npm install  prettier-plugin-gherkin --save-dev
  

  Note that usually it is enough to install the package for a Prettier plugin for Prettier to locate it and additional configuration is not required.

  Likewise, ESLint complained when it encountered .cy.ts files containing Cypress interaction tests for my app. To resolve this linting error, I installed the NPM package for Cypress ESLint plugin and configured it as described here (unlike Prettier, to get this ESLint package to work, some configuration was required).

• The typescript config might be too strict and there might be a lot of errors when you build, such as:

  

  If you do not want to fix individual errors in your existing codebase, and they are too many to disable specific rules at error locations using ESLint comments (see below), then the simplest solution would be to disable the @typescript-eslint/recommended-type-checked config by commenting it out in .eslintrc.js and uncommenting @typescript-eslint/recommended which is less strict.

• Sometimes it is safe to turn off a linting rule at a specific line or for a whole file. While I am always wary of doing this, in a (deliberately bad) experimental code file, I had many instances of an error that VS Code ESLint extension pointed. This was not caught before but was now being pointed out because strict TypeScript linting rules had been enabled:

  

  So I pressed Ctrl + . to Show Code Actions (I could instead have clicked the yellow lighbulb icon shown next to the issue), then selected “Disable @typescript/no-non-null-assertion for the entire file”.

  

  This placed the comment /* eslint-disable @typescript-eslint/no-non-null-assertion */ on top of my file to disable all instances of that particular error within the file:

  

Conclusion

This tutorial showed you how to configure linting and formatting tools in your Next.js app. I hope that it also gave you the background necessary both to understand the configurations given, and to customize them as needed.

As a React developer, maintaining code quality is essential for building robust and maintainable applications. Fortunately, there's a powerful tool called ESLint that can significantly improve the quality of your React projects.

In this article, we will explore how ESLint works and create a sign-up button component to demonstrate its benefits.

What is ESLint?

ESLint is a popular open-source JavaScript linting utility. It analyzes your code for potential errors, and enforces coding standards while improving code quality.

It can also help you as a developer to identify and fix common mistakes, use best practices, and maintain consistency across your codebase.

You can integrate ESLint seamlessly into your React projects, providing real-time feedback and improving your overall code quality.

How to Set Up Your Project

Let's start by setting up a new React project and installing ESLint. To demonstrate this, we will create a signup app in React.

Imagine that we want to store our project on the desktop, so first we will set up our file structure. Let's start by creating a root directory for our project on the desktop (eslintExample in this case).

mkdir eslintExample 
cd eslintExample

Install the React app

Now we'll use create-react-app to set up our React app.

npx create-react-app signup-app

Install ESLint

And you can use the following command to set up ESLint:

npm install eslint eslint-plugin-react eslint-plugin-react-hooks --save-dev

Your directory structure should look like this:

eslintExample/
  └── signup-app/
      └── node_modules/
      └── public/
      └── src/
          └── App.css
          └── App.js
          └── App.test.js
          └── SignupButton.js
          └── index.css
          └── logo.svg
          └── reportWebVitals.js
          └── setupTests.js
      └── .eslintrc.json
      └── .gitignore
      └── package-lock.json
      └── package.json
      └── README.md

How to Configure ESLint in a React Project

To work with ESLint in our React project, we need to configure it. To do this, the first step is to create a .eslintrc.json file in the project's root directory and add the following code:

{
    "env": {
      "browser": true,
      "es2021": true
    },
    "extends": ["eslint:recommended", "plugin:react/recommended", "plugin:react-hooks/recommended"],
    "parserOptions": {
      "ecmaVersion": 12,
      "sourceType": "module",
      "ecmaFeatures": {
        "jsx": true
      }
    },
    "plugins": ["react", "react-hooks"],
    "rules": {
      //add customize rules here as per your project's needs
    }
}

The above configuration sets up ESLint to work with React and React Hooks using the recommended configurations. You can add or customize rules according to your project's specific requirements.

Created the.eslintrc.json file and added the configuration that allows ESLint to work with React.

How to Create the Signup Button Component

Now, let's create a simple Signup Button component (SignupButton.js) inside the "src" folder.

Inside the src file, create the SignupButton.js file. It should look like this: src/SignupButton.js. Inside your SignupButton.js, paste the following code:

import React from "react";

const SignupButton = () => {
  const handleSignup = () => {
    alert("Sign up successful!");
  };

  return (
    <button onClick={handleSignup} className="signup-button">
      Sign Up
    </button>
  );
};

The above component is a basic button that triggers an alert when clicked, simulating the signup process. Now you can run this command:

npm start

This will start our React app at the root of the project. Then you should see this error below:

We started the local server, and we are seeing an error coming from the app.js file. React needs to be imported in app.js file. We need to export our button component.

This error might confuse you, because you may not know where it's coming from. We are seeing this error because we set up ESLint in our project, and it scans through our project to tell us that React needs to be imported in the app.js file.

But let’s run ESLint to see where the exact error is coming from.

How to Run ESLint

With ESLint configured, let's run it to analyze our SignupButton component for potential issues. Open your terminal and run the following command at the root of your project:

npx eslint src/SignupButton.js

ESLint will analyze the SignupButton.js file and display any problems it finds below.

We run the eslint command to show us where we are having error: in the signup button and app.js

How to Fix the ESLint Issues

From the above, you can see that ESLint identifies where we are having errors. We did not import React in our App.js file, and we did not export our signup button component. Let’s fix that.

We imported React in the app.js file and exported SignupButton component.

As you can see, our code was now built successfully.

We were able to export our SignupButton component and imported React in App.js component. This solves our problem.

If ESLint identifies any further issues in our SignupButton component, it will display them along with suggestions on how to fix them.

For example, ESLint might detect missing semicolons, unused variables, or violations of React best practices like the import React from “react” in the app.js file.

By addressing the issues highlighted by ESLint, we can ensure that our code adheres to best practices, is easier to read, and has fewer potential bugs.

Conclusion

ESLint is an indispensable tool for React developers to maintain code quality and improve productivity. By integrating ESLint into your React projects, you can catch errors early, follow coding standards, and foster collaboration within your team.

In this article, I have explained how to set up ESLint in a React project and demonstrate its benefits with a simple Signup Button component. By utilizing ESLint effectively, you can write cleaner, more consistent code and deliver higher-quality React applications.

So, why wait? Start using ESLint in your React projects and watch your code quality soar. Happy coding! 🚀

Your feedback is highly appreciated.
you can follow me on twitter and linkedIn

We're going to talk about what these tools are, how they work, why are they useful, and finally see how we can implement them in a basic React project.

Let's go!

Table of Contents

• About linting tools

  • What are Linting Tools?

  • Why are Linting Tools Useful?

  • Main Linting Tools in the Market

• About code formatters

  • What are Code Formatters?

  • Why are Code Formatters Useful?

  • Main Code Formatters Available

• How to Implement ESLint and Prettier

  • How to Install ESLint

  • How to Install Prettier

• Wrapping up

About Linting Tools

In the world of web development, linting tools have become an essential part of the developer's toolkit.

Linting tools are used to analyze source code for potential errors or stylistic issues, making it easier to maintain code quality and consistency across a project.

What are Linting Tools?

Linting tools are automated tools that analyze source code to detect potential errors, security vulnerabilities, or coding style issues.

They are designed to help developers catch mistakes before they become a problem, and to promote best practices in coding.

The term "lint" comes from the name of the first lint tool, which was developed in the early 1970s by a team of Bell Labs researchers led by Stephen C. Johnson.

The original lint tool was designed to analyze C source code for potential errors and stylistic issues.

Since then, linting tools have evolved to work with a variety of programming languages, including JavaScript, Python, and Ruby.

Why are Linting Tools Useful?

Linting tools are useful for a number of reasons. Firstly, they help you catch errors early in the development process, when they are easier and cheaper to fix.

Secondly, they can help promote coding standards and best practices within a development team, ensuring that code is consistent and maintainable.

Finally, they can help you identify potential security vulnerabilities in your code, reducing the risk of a breach.

Main Linting Tools in the Market

There are several linting tools available in the market today. Here are some of the most popular ones:

1. ESLint: ESLint is a widely used and highly configurable linter for JavaScript and TypeScript. It can be extended using plugins and supports various rule sets, making it a flexible tool for enforcing coding standards and preventing errors.

2. JSHint: JSHint is a popular linter that has been around since 2010. It offers a simple configuration and a wide range of built-in rules to help developers avoid common pitfalls and improve code quality.

3. JSLint: JSLint was one of the first linters to be developed for JavaScript, and it still sees some use today. It is known for its strictness and for enforcing a particular style of code, which can be helpful for maintaining consistency across a team.

4. StandardJS: StandardJS is a popular linter that aims to provide a "batteries included" approach to JavaScript linting. It has a minimal configuration and includes a set of opinionated rules designed to promote clean, readable code.

And we should also talk about Typescript. When using TypeScript, the TypeScript compiler itself acts as a linter. It checks the syntax of TypeScript code and provides warnings and errors when there are issues. This built-in linter can catch common mistakes and issues such as misspelled variable names, invalid method calls, and syntax errors.

The TypeScript compiler can be run using the tsc command in a terminal. When the --noEmit flag is used, the TypeScript compiler will only perform a syntax check without compiling the code to JavaScript. This allows the compiler to act as a linter and provide feedback on code quality without actually generating any output.

You can also configure the TypeScript compiler using a tsconfig.json file to specify various options, including the strictness of the checking. This can help catch even more potential issues and ensure that the code follows best practice

If you're not familiar with TypeScript, I recommend you this article I wrote a while ago.

About Code Formatters

In modern web development, code formatters have become an essential tool for developers. These tools automate the process of code formatting, making it easier to write and read code.

What are Code Formatters?

Code formatters are automated tools that help you format source code automatically. The main purpose of code formatters is to standardize the formatting of code across a project or team, making it easier to read and understand code.

With code formatters, developers no longer need to spend time formatting code manually, which can save a lot of time and effort.

Code formatting tools have been around for decades. One of the earliest tools was the "indent" program, which was used to format C code in the early 1970s. But these early tools were limited and didn't have the same level of functionality as modern code formatters.

In the early 2000s, tools like "astyle" and "uncrustify" were developed, which introduced more advanced formatting capabilities.

Why are Code Formatters Useful?

Code formatters are useful for a variety of reasons. First and foremost, they help to standardize code formatting, which makes it easier to read and understand code. This is particularly important when working on large projects with multiple developers, where everyone needs to be able to read and understand each other's code.

Code formatters also help to ensure that code is consistent across a project or team, which can help to prevent errors and improve code quality. They also make it easier to maintain code over time, as the code is formatted consistently and is easier to read and understand.

Main Code Formatters Available

There are several code formatting tools available in the market today. Here are some of the most popular ones:

1. Prettier: Prettier is a popular code formatter for JavaScript, TypeScript, and CSS. It's highly configurable and can be used in a variety of different environments, including editors, build tools, and code quality checkers.

2. ESLint: While primarily known as a linting tool, ESLint can also be used as a code formatter. It has a --fix flag that can automatically format your code based on rules you define.

3. Beautify: Beautify is a code formatter for JavaScript, HTML, and CSS that can be used in a variety of editors and IDEs. It allows you to customize your formatting options and has support for a wide range of languages.

How to Implement ESLint and Prettier

Cool, so now let's see a linter and code formatter in action! We're going to implement the two most popular tools (ESLint and Prettier) in a simple React project to get an idea of how these things work.

First let's create our project by running this in our command line: npm create vite@latest linternsAndFormatters --template react

Then cd into your project and run npm install so our dependencies get installed.

Now that we have our project up and running, we'll start by installing ESLint.

How to Install ESLint

To install ESLint, we can just run npm init @eslint/config in our console. This will fire a series of prompts asking how we want to use ESLint in our project and building the corresponding config. Your console might end up looking something like this:

Installing ESLint

After all this, we'll see a new file called .eslintrc.cjs in the root of our project. Here's where ESLint's config lives and where we can customize the linter to our preferences. The initial config given the options I selected is the following:

module.exports = {
    "env": {
        "browser": true,
        "es2021": true
    },
    "extends": [
        "eslint:recommended",
        "plugin:react/recommended"
    ],
    "overrides": [
    ],
    "parserOptions": {
        "ecmaVersion": "latest",
        "sourceType": "module"
    },
    "plugins": [
        "react"
    ],
    "rules": {
    }
}

To see our linter in action, let's add the following script in our package.json file:

"lint": "eslint --fix . --ext .js,.jsx"

This script executes the eslint command with the --fix option to automatically fix linting errors and warnings. The command is executed on all files with the .js or .jsx extension located in the root directory of the project, as specified by the . argument.

Now let's modify our app.jsx file to have the following code:

import React from 'react'
import './App.css'

function App() {

  const emptyVariable = ''

  return (
    <div className="App">
      <h1>Vite + React</h1>
    </div>
  )
}

export default App

Then run npm run lint and voilà! Your linter is screaming with red highlighted text that you have an unused variable in your code! =D

How to Install Prettier

Cool, now let's hop on to our code formatter.

We're going to install it by running npm install --save-dev --save-exact prettier.

Then we're going to create and empty config file by running echo {}> .prettierrc.json.

Since we're here, add the following options to your newly created config file:

{
  "singleQuote": true,
  "jsxSingleQuote": true,
  "semi": false
}

What this does is assure single quotes are used whenever possible and semicolons are nowhere to be found (because, god, who likes semicolons...).

As we did with our linter, let's add the following script in our package.json file:

    "format": "prettier --write ."

The script runs the Prettier code formatter on all the files in the project directory and its sub-directories. When run with the --write option, it modifies the files in place, changing them to conform to Prettier's rules for indentation, line length, and other formatting options. The . argument specifies that all files in the project directory and its sub directories should be formatted.

Lastly, let's "uglify" the first line of our app.jsx file like this:

import React from "react";

Run npm run format and you should see it corrected right in front of you:

import React from 'react'

You can breath easy now, those ugly semicolons won't come back to haunt you. ;)

As we've seen, the set up of these two tools isn't that complex, and they truly help to make our everyday jobs easier. ESLint will help us catch bugs and unnecessary/redundant code, and Prettier will help us standardize code format all across our codebase.

Another tip is that if you have a CI/CD pipeline in place, it's a good idea to implement the linting and formatting scripts as part of your workflow. This will help you ensure that every deployment is both automatically linted and formatted.

If you're not familiar with CI/CD or setting up a pipeline, I recently wrote an article about that. ;)

Wrapping up

Linters and code formatters are powerful tools that can greatly benefit web developers.

Linters help you catch potential bugs and issues before they become serious problems, and encourage you to write more maintainable and readable code.

Code formatters help you enforce a consistent code style and format, saving time and reducing the chances of human error.

By using these tools in your web development workflow, you can improve your productivity and the quality of your code.

As always, I hope you enjoyed the article and learned something new.

If you want, you can also follow me on LinkedIn or Twitter. See you in the next one!

This is why code formatters are so useful.

A code formatter is a tool that formats code according to certain standards. It makes it so you don't have to worry as much about code formatting. Instead, you can focus on writing good code. This save time and also reduces your stress.

In this guide, we will talk about the Prettier code formatter. We will also talk about alternatives to Prettier like JsFmt, StandardJS, EsLint + EditorConfig, and Beautifier. Hopefully you’ll take away something that you can use to improve your code formatting.

Brief Overview of Prettier

Prettier is a popular code formatter that can handle complex code structures and format your code in a readable way.

It operates on the principle of no configuration required and it's designed to produce readable, consistent code.

Prettier is an opinionated tool that encourages programmers to follow its formatting rules. It also parses the code and reprints it uniformly.

Why Explore Alternatives to Prettier?

There are many advantages of using Prettier. But like every other tool, exploring alternatives is sometimes a good idea. Here are some of the reasons for exploring alternatives to Prettier:

1. Inflexible style guides: Prettier adopts a strict set of formatting rules, and does not allow for much customization. Some programmers want a tool with a lot of configurations available.
2. Speed: Although Prettier is fast, you may need a tool that provides faster and better performance in large codebases or real-time formatting.
3. Language support: Prettier may not support (or might offer inadequate support) for the language you use.
4. More features: While Prettier is open source, you might prefer a paid code formatter that has more features and better integration with other tools.

In the guide, we will talk about four alternatives to Prettier. They are:

• JsFmt
• StandardJS
• ESLint+EditorConfig
• JS Beautifier

JsFmt Overview

JsFmt is a code formatter that uses esformatter as a formatting tool. It automatically reformats JavaScript code according to a set of predefined rules. It is available specifically to re-write, format, search, and validate JavaScript code.

To install JsFmt, run this command:

npm install -g jsfmt

A .jsfmtrc file, which can either be a JSON or INI formatted file, can overwrite any of the esformatter formatting options.

{
  "indent": 4,
  "line_ending": "unix",
  "quote": "single"
}

In this example, we specified the spaces for indentation to be four, we chose line-ending to be unix, and we picked single as the quote style for strings.

You can use the jsfmt rewrite method to change values in your JavaScript code. Here's an example of how to do that:

const x = 5;
const y = 10;
const z = x + y;
console.log(z);

//  The output will change to the below code after writing:  npx jsfmt --rewrite '5 -> 20' reduce.js

const x = 20;
const y = 10;
const z = x + y;
console.log(z);

To learn more about JsFmt, you can read its documentation here.

Features of JsFmt

1. Formating: JsFmt can format code according to a set of predefined rules.
2. Integrations: you can integrate JsFmt with popular code editors like Visual Studio Code, Sublime Text, and Atom, making it easy to format your code directly in your editor.
3. Command-line interface: JsFmt allows you to format your code as part of your build process or development workflow in the command line.

JsFmt Formatting Rules

Some of the formatting rules adopted by JsFmt are as follows

1. Set indent: With the --indent option, JsFmt indents your code with two spaces per level.
2. Quotes: In JsFmt, single quotes are the default for strings, but you can change this with the --double-quote option.
3. Wrapping: you can use --linene-width to change the default wrap lines setting in JsFmt.
4. Semicolons: JsFmt adds semicolons at the end of each statement by default. You can disable this using the --no-semi option.

Pros of JsFmt

1. Formatting, searching, and re-writing of JavaScript.
2. Customizable: JsFmt's flexibility makes it a popular choice for many development teams. It is a highly customizable tool that you can configure to match the specific requirements of a project.

Con of JsFmt

1. Lack of flexibility: despite the fact that it's customizeable, certain parts of JsFmt may not always be configurable to match the needs of your project.

StandardJS Overview

StandardJS is an open-source, no configuration linter, formatter, and JavaScript style guide. It checks the code for probable errors with the linter. It also formats code automatically, and helps you write code that is easy to read and understand.

It is the most popular option, coming in at 27,905 stars on GitHub clean code linter. It is also a powerful tool for ensuring the quality and consistency of your JavaScript code.

You can either install it globally or locally on your machine. To install globally, use the first command, while the second command is for installing locally. Note that to install it, you must have Node and npm installed on your computer.

To install globally: $ npm install standard --global

To install locally: $ npm install standard --save-dev

Alternatively, you can add StandardJS to the package JSON.

{
  "name": "my-cool-package",
  "devDependencies": {
    "standard": "*"
  },
  "scripts": {
    "test": "standard && node my-tests.js"
  }
}

The styles are checked automatically when you run the command:

npm test

To illustrate how it works, check the JavaScript code below:

let number = 10;
if (number == 10) {
  alert("yes");
} else {
  alert("no");
}

// The Output after running the npm test in the terminal

> test
> standard && node my-tests.js

standard: Use JavaScript Standard Style (https://standardjs.com)
  C:\Users\hp\Desktop\pretier\Js\script.js:5:5: Parsing error: Unexpected token else (null)

StandardJS shows that the code has a parsing error.

To fix most issues, run the following code:

standard --fix

Features of StandardJS

1. Community: A community of contributors guides the development of StandardJS by providing bug fixes and new features.
2. Linting: StandardJS linting catches style issues and programmer errors early.
3. Automatic code formatting: StandardJS get rid of messy and inconsistent code.
4. Command line integration: It has a command-line interface for running linter checks and auto-formatting code.

StandardJS Formatting Rules

Some of the widely used StandardJS formatting rules are listed below:

1. Indentation: StandardJS enforces a consistent indentation level of 2 spaces by default. To strictly implement this, you need to add the --fix option.
2. Line wrap: StandardJS doesn't enforce the rule of line length, but it recommends keeping lines shorter than 80 characters. Use $ myfile.js | standard --stdin to manually check the file length.
3. Semicolons: StandardJS recommends using semicolons for clarity and to avoid potential issues. But the tool doesn't enforce this. To enforce the use of semicolons, use this:

{
  "extends": "standard"
}

1. Spaces around operators: StandardJS recommends using spaces around operators, such as + and -, but it doesn't enforce this rule.

Pros of StandardJS

1. Zero configuration: No decisions to make. StandardJS is the easiest way to enforce code quality in your project.
2. Easy installation: StandardJS is easy to install, and you can use it with most editors and IDEs.
3. Enhances Productivity: StandardJS saves developers time and increases productivity by formatting code according to its rules.
4. Wide support: Most editors and IDEs support StandardJS using plugins and integrations.
5. Consistency: StandardJS promote consistency across projects by enforcing a strict set of coding rules.

Cons of StandardJS

1. Opinionated: Some developers may find the tool too opinionated. If that's the case, you might prefer to use other linting tools that allow for more customization.
2. Limited flexibility: StandardJS enforces a strict set of rules and conventions, which some developers may feel restricted by and prefer a more customizable approach.

ESLint + EditConfig Overview

ESlint provides configurable rules that you can tailor according to your specific project needs. It is one of the most popular JavaScript linter that analyzes programming errors, bugs, and suspicious constructs.

You can extend its functionality by adding plugins, which can provide custom parsers and extra rules.

You'll need Node installed on your before installing ESLint. To install it, use the command below:

npm init @eslint/config

Alternatively, you can create this manually on your machine:

npm install --save-dev eslint

For both installations, you need to have installed a package.json file. If not, run this command

npx eslint --init

The command will ask a series of questions about your project, coding style, and preferences to generate your configuration file.

You can run ESLint on any of your directories or files with this command:

npx eslint yourfile.js

Rules can be turned off and you can run the toolonly with basic syntax validation, as ESLint is configurable and flexible to your use case.

Once you have generated the configuration file, you can customize according to your needs. The configuration file is a JavaScript file that exports an object with the configuration settings.

For example, you can specify the rules you want, plugins to use, and environments for your code:

{
  "rules": {
    "semi": ["error", "always"],
    "quotes": ["error", "double"],
    "indent": ["error", 4]
  }
}

The semi, quotes, and indent are the names of the rules in ESLint, while the error level of the rule is the first value. There are only three outputs for the first values. They are:

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

{
  "env": {
    "browser": true,
    "es2021": true
  },
  "extends": "eslint: recommended",
  "overrides": [],
  "parserOptions": {
    "ecmaVersion": "latest"
  },
  "rules": {
    "indent": ["error", 4],
    "quotes": ["error", "single"],
    "semi": ["error", "never"]
  }
}

In this example, you specify that your code should run in a browser environment. Enable ECMAScript 2018 syntax, and follow the ESLint rules. You've also enabled three specific rules: indent, quotes, and semi.

The indent rule determines that an alert error will be thrown if indentation is more than 4 spaces. Likewise if you use double-quotes instead of single, there will be an error. You also specified not to use semi-colons.

To fix most of the issues in ESLint, use this command:

npx eslint yourfile.js --fix

Here's an example:

const numbers = [1, 3, 5, 2, 6, 78, 8];
let peoples = ["shola", "kamal"];
console.log(peoples);

// The output

 error  'numbers' is assigned a value but never used  no-unused-vars
   error  Extra semicolon                               semi

✖ 2 problems (2 errors, 0 warnings)
  1 error and 0 warnings potentially fixable with the `--fix` option.

EditorConfig Overview

EditorConfig is an open-source file format. It provides standard ways of defining and maintaining coding styles in a project.

It maintains consistent coding styles which is especially useful when you have many developers working on the same project across various editors and IDEs. The tool consists of a collection of text editor plugins that enable editors to read the file format and adhere to defined styles.

You'll need to create a file named .editorconfig in the directory. EditorConfig plugins will look for the file in the directory of the opened file and on every parent directory.

Files are read from top to bottom, and a search for .editorconfig files will stop if the root file path is reached.

Creating an EditorConfig file is straightforward. Open a new file, and save it with .editorconfig as shown below.

Inside the .editorconfig file, the following wildcard patterns are used:

root = true

[*]

indent_size = 4
indent_style = space
end_of_line = lf
insert_final_newline = true

 // Set root to true: A search for .editorconfig files will stop if the root file path is reached or an EditorConfig file with root=true is found.

 //[*]: Except for path selectors, it matches any string of characters.

 //indent_size: Indent size is set to 4. 
 //Indent_style: set to space
 //end_of_line: Set to lf
//insert_final_newline: Set to true

To know more about the wildcards pattern, visit the EditorConfig docs.

Using ESLint and EditorConfig together can help to spot potential issues early. It also ensures that your code is consistent, maintainable, and of high quality.

The combination of ESLint and EDitorConfig saves you time on code maintenance and debugging.

Features of ESLint

1. Configurable: ESLint allows you to customize and add your own rules to the configuration file.
2. Support ECMAScript: ESLint ensures your code is compatible with the latest language features.
3. Supports many file formats: ESLint can analyze JavaScript code in a variety of file formats, including but not limited to .js, .jsx, and .vue.
4. Integration: ESLint integrates seamlessly with Webpack and Gulp, which are popular build tools.

ESLint Formatting Rules

Some of the popular formatting rules in ESLint are listed below:

1. Indentation: ESLint by default expects a four-space per level indent. But you can customize this using the popular --fix option.
2. Semicolons: ESLint enforces the use of semicolons at the end of each statement. This rule is set to "always" by default. Use the popular --fix option to reset it to "never".
3. Line wrap: Use the max-len rule to change the maximum line length from the default 80 to your preferred value.
4. Quotes: The quotes rule can be changed from the default value of "single" to "double" using the --fix option.

Pros of ESLint

1. Saves time: ESLint saves time by reducing the amount of time spent on manual code reviews and debugging.
2. Active Community: ESLint has a wide and active community base that contributes to the development of the tool and its ecosystem.
3. Code analyzer: ESLint analyze your code to quickly find problems.
4. Consistency: ESLint helps in maintaining clean and readable code by enforcing a consistent coding style.

Cons of ESLint

1. Rule conflicts: With a large set of rules, ESLint rules can sometimes conflict with one another, resulting in more configuration and fine-tuning.
2. Steeper learning curve: ESLint has a pretty steep learning curve, as it has many rules and learning how to configure them can take time.
3. False positives: ESLint can sometimes flag code as problematic code even when it is correct, which can be frustrating for developers.

Overview of JS Beautifier

JavaScript Beautifier, also known as js-beautify, is an open-source, cross-platform command-line tool. It is a beautifier for re-formating and re-indenting bookmarklets, ugly JavaScript, and it partly deobfuscates scripts.

You can install JS beautifier both locally and globally.

Run npm -g install js-beautify to install globally, and npm install js-beautify to install locally.

You can configure it through the command line option.

After local installation, you can import and call the appropriate beautifier methods for JS, CSS, or HTML. An example of how to call the methods goes like this: beautify (code, options).

While code is the string of code to be beautified, options is an object with the settings you would like used to beautify the code. See the example below for a JavaScript script file:

npx beautify("script.js",{indent_size:4})

You can also configure it through a configuration file:

{
  "indent_size": 4,
  "indent_char": " ",
  "indent_with_tabs": false,
  "brace_style": "collapse"
}

Create a file .jsbeautifyrc in the root directory of your project. This option will override the default option of JS beautifier. You can also use Beautifier on your web browser. Learn more about JSbeautifer from its docs here.

Feature of JS Beautifier

1. Formatting: You can customize JS Beautifier to fit your personal preferences and coding style because it offers varieties of formatting options, such as indentation size and braces style.
2. Online version: You can beautify JavaScript using JS Beautifier in your web browser, just as you can on the command line.

JS Beautifier Formatting Rules

1. Indentation: The default identation in JS Beautifier is 4 spaces, but you can change it to 2 or 8 spaces, or use tabs instead. Use the indent_size option to specify the number of spaces to use for indentation.
2. Semicolons: You can change your semicolon settings in JS Beautifier with the semicolon option. You change this by alternating the value of the semicolon option between "true" or "false".
3. Line wrap: Use the max_char option to limit each line to 80 characters. You can set the value of the max_char to 80 or any other preferred number.

Pros of JS Beautifier

1. Time-saving: JS Beautifier saves time. It automates the many steps of formatting and organizing code.
2. Online presence: JS Beautifier's online presence is a game changer, as a lot of non-developers will be able to use it.
3. Detects errors: JS Beautifier helps catch small errors that can be difficult to spot otherwise.
4. Integration: JS Beautifier's compatibility with varieties of code editors and IDEs makes it a versatile tool.

Cons of JS Beautifier

1. Complexity: Despite having an online version, JS Beautifier is somewhat complex for beginners.
2. Potential for over-formatting: In some cases, JS Beautifier may make the code harder to read because of over-formatting.

Results from all the Formatting Tools

We'll use the code sample below to test how these four popular tools format code:

const numbers = [2,3,8,9,7]

          let peoples = ['kamal', 'lawal', "shola", "olaide"];

As you can see, this code isn't properly formatted. So let's try the tools to see how they help.

Formatting example with JsFmt

Using the above code as a sample, the command npx jsfmt --write "Your file" will format the code to this:

const numbers = [2, 3, 8, 9, 7]

let peoples = ['kamal', 'lawal', "shola", "olaide"];

As you can see, there is a noticeable change in the code, and you can configure this to your desired taste.

Formatting example with StandardJS

By running the popular npx standard--fix command from the terminal, you will have the following result.

const numbers = [2, 3, 8, 9, 7]

const peoples = ['kamal', 'lawal', 'shola', 'olaide']

Notice the code was properly formatted, most especially the elements with double quotes within the peoples array.

Formatting example with ESLint

Using the same code as above, the npx eslint "Your file name --fix" command will quickly format to this:

const numbers = [2,3,8,9,7]

let peoples = ['kamal','lawal','shola','olaide']

You can also change the configuration of the tool, by changing the elements of the peoples array so they're inside double quotes:

const numbers = [2,3,8,9,7]

let peoples = ["kamal","lawal","shola","olaide"];

You can do this by going to the .eslintrc file and manipulating the rules like this:

{
  "quotes": ["error", "double"],
  "semi": ["off", "always"]
}

Formatting example with JS Beautifier

Here's the result from JS Beautifier for the same code:

const numbers = [2, 3, 8, 9, 7]
let peoples = ['kamal', 'lawal', "shola", "olaide"];

You can configure it more from your JSON file if you wish.

Now you've seen these formatters in action!

Conclusion

In this guide, we talked about some alternatives to using Prettier. We discussed Jsfmt, ESlint, StandardJS, and JS Beautifier, as well as their features, pros, and cons.

I hope you are now more equipped to choose the right linter/formatter for your coding projects.

In this article, we'll build a web application using the latest version of Angular. Then we'll add ESLint which analyzes the JavaScript code statically to find any problems.

Prerequisites

Before you start, you need to install and configure the tools below (if you don't already have them installed) to create the Angular application:

• Git: Git is a distributed version control system. We'll use it to sync the repository.
• Node.js and npm: Node.js is a JavaScript code runtime software based on Google's V8 engine. npm is a package manager for Node.js (Node Package Manager). We'll use them to build and run the Angular application and install the libraries.
• Angular CLI: Angular CLI is a command line utility tool for Angular. We'll use it to create the base structure of the Angular application.
• IDE (for example Visual Studio Code or WebStorm): an Integrated Development Environment is a tool with a graphical interface to help in the development of applications. We'll use it to develop the Angular application.

Getting Started

Create the Angular application

Angular is a development platform for building web, mobile and desktop applications using HTML, CSS, and TypeScript (JavaScript). Currently, Angular is at version 14 and Google is the main maintainer of the project.

First, let's create the application with the Angular base structure using the @angular/cli with the route file and the SCSS style format.

ng new angular-eslint --routing true --style scss
CREATE angular-eslint/README.md (1067 bytes)
CREATE angular-eslint/.editorconfig (274 bytes)
CREATE angular-eslint/.gitignore (548 bytes)
CREATE angular-eslint/angular.json (3136 bytes)
CREATE angular-eslint/package.json (1045 bytes)
CREATE angular-eslint/tsconfig.json (863 bytes)
CREATE angular-eslint/.browserslistrc (600 bytes)
CREATE angular-eslint/karma.conf.js (1431 bytes)
CREATE angular-eslint/tsconfig.app.json (287 bytes)
CREATE angular-eslint/tsconfig.spec.json (333 bytes)
CREATE angular-eslint/.vscode/extensions.json (130 bytes)
CREATE angular-eslint/.vscode/launch.json (474 bytes)
CREATE angular-eslint/.vscode/tasks.json (938 bytes)
CREATE angular-eslint/src/favicon.ico (948 bytes)
CREATE angular-eslint/src/index.html (299 bytes)
CREATE angular-eslint/src/main.ts (372 bytes)
CREATE angular-eslint/src/polyfills.ts (2338 bytes)
CREATE angular-eslint/src/styles.scss (80 bytes)
CREATE angular-eslint/src/test.ts (749 bytes)
CREATE angular-eslint/src/assets/.gitkeep (0 bytes)
CREATE angular-eslint/src/environments/environment.prod.ts (51 bytes)
CREATE angular-eslint/src/environments/environment.ts (658 bytes)
CREATE angular-eslint/src/app/app-routing.module.ts (245 bytes)
CREATE angular-eslint/src/app/app.module.ts (393 bytes)
CREATE angular-eslint/src/app/app.component.scss (0 bytes)
CREATE angular-eslint/src/app/app.component.html (23364 bytes)
CREATE angular-eslint/src/app/app.component.spec.ts (1097 bytes)
CREATE angular-eslint/src/app/app.component.ts (219 bytes)
✔ Packages installed successfully.
    Successfully initialized git.

Now we will install the libraries and add the ESLint settings.

ng add @angular-eslint/schematics
ℹ Using package manager: npm
✔ Found compatible package version: @angular-eslint/schematics@14.2.5.
✔ Package information loaded.

The package @angular-eslint/schematics@14.2.5 will be installed and executed.
Would you like to proceed? Yes
✔ Packages successfully installed.

    All @angular-eslint dependencies have been successfully installed 🎉

    Please see https://github.com/angular-eslint/angular-eslint for how to add ESLint configuration to your project.

    We detected that you have a single project in your workspace and no existing linter wired up, so we are configuring ESLint for you automatically.

    Please see https://github.com/angular-eslint/angular-eslint for more information.

CREATE .eslintrc.json (984 bytes)
UPDATE package.json (1511 bytes)
UPDATE angular.json (3447 bytes)
✔ Packages installed successfully.

Next, we will run the command below to validate the ESLint installation and configuration:

npm run lint

> angular-eslint@1.0.0 lint /home/rodrigokamada/angular-eslint
> ng lint


Linting "angular-eslint"...

All files pass linting.

And you're all set! The message "All files pass linting" shows that no problems were found.

The application repository is available here.

Conclusion

This is what we covered in this article:

• We created an Angular application.
• We added ESLint to analyze and find problems with the code.

You can use this to check your application code before deploying to your environment.

Thank you for reading and I hope you enjoyed the article!

This tutorial was posted on my blog in Portuguese.

To stay updated whenever I post new articles, follow me on Twitter and LinkedIn.

When you're starting a new project, you might have to add multiple linting tools to beautify your code and prevent simple errors.

You will often use multiple linters – one of them might support an npm installation and other one might have a PyPI installation and so on. You will also want to set up some automation in your CI to run these linters, but this process is quite tedious 😫.

In this article, I will show you how you can use GitHub Super Linter, a single linter to solve all these problems. Most of my personal projects use GitHub Super Linter as well, and I have personally found it be a huge lifesaver.

Why is Linting Necessary?

Linting is essentially a form of static code analysis. It analyzes the code you wrote against some rules for stylistic or programmatic errors. Think of it as a tool that flags suspicious usage in software.

A linter can help you save a lot of time by:

• Preventing broken code from being pushed
• Helping establish coding best practices
• Building guidelines for code layout and format
• Helping code reviews be a lot smoother
• Flagging bugs in your code from syntax errors

Given the useful nature of linting tools, you would ideally want to run a linter before any code reviews happen on every single piece of code that is pushed to your repository. This definitely helps you write better, more readable, and more stable code.

Here is an example of using Black, a linting tool for Python focusing on code formatting.

Formatting changes made by Black

GitHub Super Linter can help you quite a lot in bringing these capabilities to your projects easily and efficiently. GitHub Super Linter is a combination of multiple commonly used linters which you can use very easily. It lets you set up automated runs for these linters, as well as manage multiple linters in a single project!

There is also a ton of customization capabilities with environment variables that can help you customize the Super Linter to your individual repository.

How to Use GitHub Super Linter in GitHub Actions

Super Linter is primarily designed to be run inside a GitHub Action, which is also how I have been using it for quite some time. We will talk about this first. To follow along you should create a new GitHub Action in your repository. Let us create a new file at .github/workflows/linter.yml.

Going forward, I will assume you know about the basic syntax for GitHub Actions. But in case you do not or need a quick refresher, I would suggest going through this Quick Start Guide.

How to Create an Action

We already have a blank file .github/workflows/linter.yml, which we will now populate with an action you can use to lint your project.

We will start by giving our action a name. This is what appears under the GitHub Action Status Check:

name: Lint Code Base

Next up, let's specify triggers for our action. This answers the question of when you should lint your codebase. Here we tell it to run the lint on every push and on every pull request.

name: Lint Code Base

on: [push, pull_request]

This is another very commonly used configuration for the triggers. This only runs when you make a pull request to main or master branches and not on pushes to these branches.

on:
  push:
    branches-ignore: [master, main]
  pull_request:
    branches: [master, main]

Next up, we want to set up a job. All the components you put in a single job will run sequentially. Here, think of it as the steps and in which order we want them to run whenever the trigger is satisfied.

We will name this job "Lint Code Base" and ask GitHub to run our job on a runner with the last version of Ubuntu supported by GitHub.

name: Lint Code Base

on: [push, pull_request]

jobs:
  build:
    name: Lint Code Base
    runs-on: ubuntu-latest

You are not bound to using a single kind of runner (ubuntu-latest), like we do here. It's a common practice to have a matrix of agent kinds, but in this case it will run the same way on all kinds of runners. You often you use a matrix of runners to test that your code works well on all kinds of platforms.

GitHub Super Linter doesn't work any differently on other machine types so we just use a single machine type.

Next up, we will start defining the steps we want this workflow to have. We essentially have two steps:

1. Checkout the code
2. Run the super linter

On to checking out the code. To do this, we will use the official checkout action by GitHub.

We will set fetch-depth: 0 to fetch all history for all branches and tags which is required for Super linter to get a proper list of changed files. If you hadn't done this, only a single commit would be fetched.

We also give our step a name and tell it we want to use the action present in the GitHub repository at actions/checkout@v3 .

name: Lint Code Base

on: [push, pull_request]

jobs:
  build:
    name: Lint Code Base
    runs-on: ubuntu-latest

    steps:

      - name: Checkout Code
        uses: actions/checkout@v3
        with:
          fetch-depth: 0

This piece of code checks out your repository under $GITHUB_WORKSPACE which allows the rest of the workflow to access this repository. The repository we are checking out is the one where your code resides, ideally the same repository.

How to Run the Linter

Now we'll add the step to run the linter since we have our code checked out. You can customize GitHub Super Linter using environment variables when running the action.

name: Lint Code Base

on: [push, pull_request]

jobs:
  build:
    name: Lint Code Base
    runs-on: ubuntu-latest

    steps:

      - name: Checkout Code
        uses: actions/checkout@v3
        with:
          fetch-depth: 0

      - name: Lint Code Base
        uses: github/super-linter@v4

We will now talk about the environment variables which you will often be using with GitHub Super Linter as well as some examples.

• VALIDATE_ALL_CODEBASE: this decides whether Super Linter should lint the whole codebase or just the changes introduced with that commit. These changes are found out using git diff, but you can also change the search algorithm (but we will not be looking into this in this article). Example: VALIDATE_ALL_CODEBASE: true.
• GITHUB_TOKEN: As the name suggests, this is the value of the GitHub token. If you use this, GitHub will show up each of the linters you use (we will see how to do that soon) as separate checks on the UI. Example: In GitHub Actions you can use GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}.
• DEFAULT_BRANCH: The name of the repository default branch. Example: DEFAULT_BRANCH: main.
• IGNORE_GENERATED_FILES: In case you have any files which are generated by tools, you could mark them as @generated. If this environment variable is set to true, Super Linter ignores these files. Example: IGNORE_GENERATED_FILES: true.
• IGNORE_GITIGNORED_FILES: Excludes the files which are in .gitignore from linting. Example: IGNORE_GITIGNORED_FILES: true.
• LINTER_RULES_PATH: A custom path where any linter customization files should be. By default your files are expected to be at .github/linters/. Example: LINTER_RULES_PATH: /.

These are some of the environment variables you will use the most often, but none of the ones we've discussed yet talk about language-specific linting.

If you do not use any of the environment variables we talk about, Super Linter automatically finds and uses all the applicable linters for your codebase.

How to Add Specific Linters to Super Linter

You will often only be interested in using specific linters for your projects. You can use the following environment variable pattern to add any linters you want:

VALIDATE_{LANGUAGE}_{LINTER}

You can find the naming conventions for these in the list of Supported Linters.

Here are a couple of examples, where we specify we want to use Black to lint all Python files, ESLint for JavaScript files, and HTMLHint for HTML files.

name: Lint Code Base

on: [push, pull_request]

jobs:
  build:
    name: Lint Code Base
    runs-on: ubuntu-latest

    steps:

      - name: Checkout Code
        uses: actions/checkout@v3
        with:
          fetch-depth: 0

      - name: Lint Code Base
        uses: github/super-linter@v4
        env:
          VALIDATE_ALL_CODEBASE: true
          VALIDATE_JAVASCRIPT_ES: true
          VALIDATE_PYTHON_BLACK: true
          VALIDATE_HTML: true
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Once you set one of the linters to true, all the other linters will not run. In the above snippet, none of the linters except ESLint, Black, or HTMLHint will run.

However, in this example, we set a single linter to false so every linter except ESLint will run here:

name: Lint Code Base

on: [push, pull_request]

jobs:
  build:
    name: Lint Code Base
    runs-on: ubuntu-latest

    steps:

      - name: Checkout Code
        uses: actions/checkout@v3
        with:
          fetch-depth: 0

      - name: Lint Code Base
        uses: github/super-linter@v4
        env:
          VALIDATE_ALL_CODEBASE: true
          VALIDATE_JAVASCRIPT_ES: false
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

How to Customize Lint Checks

Linters often use configuration files so you can modify the rules the linter uses. In the above two full length examples I showed, Super Linter will try to find any configuration files under .github/linters/.

These could be your .eslintrc.yml file used to configure ESLint, .htmlhintrc for configuring HTMLHint, and so on.

Here is an example of the configuration file if you use the Flake8 linter for Python:

[flake8]
max-line-length = 120

You save this at .github/linters/.flake8. You'll then use it while running the Flake8 linter. You can find an example of template configuration files you can use here.

However, here are two examples of how you can modify this path:

1. All your linter configuration files are in some other directory

Add the directory path as an environment variable like this:

LINTER_RULES_PATH: configs/

2. Add path for a configuration file

You can also hardcode a path for a specific linter as an environment variable. Here is an example:

JAVASCRIPT_ES_CONFIG_FILE: configs/linters/.eslintrc.yml

How to Run Super Linter Outside GitHub Actions

GitHub Super Linter was built to be run inside GitHub Actions. But running it locally or on other CI platforms can be particularly helpful. You will essentially be running Super Linter as you were locally in any other CI platforms.

How to Run Super Linter Locally

You first want to pull the latest Docker container down from DockerHub with this command:

docker pull github/super-linter:latest

To run this container you then run the following:

docker run -e RUN_LOCAL=true -e USE_FIND_ALGORITHM=true VALIDATE_PYTHON_BLACK=true -v /project/directory:/tmp/lint github/super-linter

Notice a couple of things here:

• We run it with the RUN_LOCAL flag to bypass some of the GitHub Actions checks. This automatically sets VALIDATE_ALL_CODEBASE to true.
• We map our local codebase to /tmp/lint so that the linter can pick up the code.
• The way we set environment variables is of course different, but the overall process of running the GitHub Super Linter remains the same.

How to Run Super Linter on Other CI Platforms

Running GitHub Super Linter on other CI platform is pretty similar to locally running it. Here is an example of running it in Azure Pipelines by Tao Yang.

- job: lint_tests
  displayName: Lint Tests
  pool:
    vmImage: ubuntu-latest
  steps:
  - script: |
      docker pull github/super-linter:latest
      docker run -e RUN_LOCAL=true -v $(System.DefaultWorkingDirectory):/tmp/lint github/super-linter
    displayName: 'Code Scan using GitHub Super-Linter'

This just runs the commands we would have for locally running the Super Linter as a script. You could run it in the exact same way on other CI platforms.

Conclusion

Thank you for sticking with me until the end. I hope that you've taken away a thing or two about linting and using GitHub Super Linter. It has most certainly been one of my favorite open source projects.

If you learned something new or enjoyed reading this article, please share it so that others can see it. Until then, see you in the next post!

You can also find me on Twitter @rishit_dagli, where I tweet about open source and machine learning.

If you are just getting started with JavaScript, the number of tools and technologies you'll hear about may be overwhelming. And you might have a hard time deciding which tools you actually need.

Or maybe you're familiar with the tools, but you haven't given much thought to what problems they solve and how miserable your life would be without their help.

I believe it is important for Software Engineers and Developers to understand the purpose of the tools we use every day.

That's why, in this article, I look at NPM, Babel, Webpack, ESLint, and CircleCI and I try to clarify the problems they solve and how they solve them.

NPM

NPM is the default package manager for JavaScript development. It helps you find and install packages (programs) that you can use in your programs.

You can add npm to a project simply by using the "npm init" command. When you run this command it creates a "package.json" file in the current directory. This is the file where your dependencies are listed, and npm views it as the ID card of the project.

You can add a dependency with the "npm install (package_name)" command.

When you run this command, npm goes to the remote registry and checks if there is a package identified by this package name. If it finds it, a new dependency entry is added to your package.json and the package, with it's internal dependencies, is downloaded from the registry.

You can find downloaded packages or dependencies under the "node_modules" folder. Just keep in mind that it usually gets pretty big – so make sure to add it to .gitignore.

NPM does not only ease the process of finding and downloading packages but also makes it easier to work collaboratively on a project.

Without NPM, it would be hard to manage external dependencies. You would need to download the correct versions of every dependency by hand when you join an existing project. And that would be a real hassle.

With the help of npm, you can just run "npm install" and it will install all external dependencies for you. Then you can just run it again anytime someone on your team adds a new one.

Babel

Babel is a JavaScript compiler or transpiler which translates the ECMAScript 2015+ code into code that can be understood by older JavaScript engines.

Babel is the most popular Javascript compiler, and frameworks like Vue and React use it by default. That said, concepts we will talk about here are not only related to Babel and will apply to any JavaScript compiler.

Why do you need a compiler?

"Why do we need a compiler, isn't JavaScript an interpreted language?" you may ask if you are familiar with the concepts of compiled and interpreted languages.

It's true that we usually call something a "compiler" if it translates our human-readable code to an executable binary that can be understood by the CPU. But that is not the case here.

The term transpiler may be more appropriate since it is a subset of a compiler: Transpilers are compilers that translate the code from a programming language to another language (in this example, from modern JS to an older version).

JavaScript is the language of browsers. But there is a problem with browsers: Cross compatibility. JavaScript tools and the language itself are evolving rapidly and many browsers fail to match that pace. This results in compatibility issues.

You probably want to write code in the most recent versions of JavaScript so you can use its new features. But if the browser that your code is running has not implemented some of the new features in its JavaScript engine, the code will not execute properly on that browser.

This is a complex problem because every browser implements the features at a different speed. And even if they do implement those new features, there will always be people who use an older version of their browser.

So what if you want to be able to use the recent features but also want your users to view those pages without any problems?

Before Babel, we used polyfills to run older versions of certain code if the browser did not support the modern features. And when you use Babel, it uses polyfills behind the scenes and does not require you to do anything.

How do transpilers/compilers work?

Babel works similar to other compilers. It has parsing, transformation, and code generation stages.

We won't go in-depth here into how it works, since compilers are complicated things. But to understand the basics of how compilers work, you can check out the the-super-tiny-compiler project. It is also mentioned in Babel's official documentation as being helpful in understanding how Babel works.

We can usually get away with knowing about Babel plugins and presets. Plugins are the snippets that Babel uses behind the scenes to compile your code to older versions of JavaScript. You can think of each modern feature as a plugin. You can go to this link to check out the full list of plugins.

List of plugins for ES5

Presets are collections of plugins. If you want to use Babel for a React project you can use the pre-made @babel/preset-react which contains the necessary plugins.

React Preset Plugins

You can add plugins by editing the Babel config file.

Do you need Babel for your React App?

For React, you need a compiler because React code generally uses JSX and JSX needs to be compiled. Also the library is built on the concept of using ES6 syntax.

Luckily, when you create a project with create-react-app, it comes with Babel already configured and you usually do not need to modify the config.

Examples of a compiler in action

Babel's website has an online compiler and it is really helpful to understand how it works. Just plug in some code and analyze the output.

Webpack

Webpack is a static module bundler. When you create a new project, most JavaScript frameworks/libraries use it out of the box nowadays.

If the phrase "static module bundler" sounds confusing, keep reading because I have some great examples to help you understand.

Why do you need a bundler?

In web apps you're going to have a lot of files. This is especially the case for Single Page Applications (React, Vue, Angular), with each having their own dependencies.

What I mean by a dependency is an import statement – if file A needs to import file B to run properly, then we say A depends on B.

In small projects, you can handle the module dependencies with <script> tags. But when the project gets larger, the dependencies rapidly become hard to manage.

Maybe, more importantly, dividing the code into multiple files makes your website load more slowly. This is because the browser needs to send more requests compared to one large file, and your website starts to consume a ton of bandwidth, because of HTTP headers.

We, as developers want our code to be modular. We divide it into multiple files because we do not want to work with one file with thousands of lines. Still, we also want our websites to be performant, to use less bandwidth, and to load fast.

So now, we'll see how Webpack solves this issue.

How Webpack works

When we were talking about Babel, we mentioned that JavaScript code needs to be transpiled before the deployment.

But compiling with Babel is not the only operation you need before deploying your project.

You usually need to uglify it, transpile it, compile the SASS or SCSS to CSS if you are using any preprocessors, compile the TypeScript if you are using it...and as you can see, this list can get long easily.

You do not want to deal with all those commands and operations before every deployment. It would be great if there was a tool that did all that for you in the correct order and correct way.

The good news – there is: Webpack.

Webpack also provides features like a local server with hot reload (they call it hot module replacement) to make your development experience better.

So what's hot reloading? It means that whenever you save your code, it gets compiled and deployed to the local HTTP server running on your machine. And whenever a file changes, it sends a message to your browser so you do not even need to refresh the page.

If you have ever used "npm run serve", "npm start" or "npm run dev", those commands also start Webpack's dev server behind the scenes.

Webpack starts from the entry point of your project (index) and generates the Abstract Syntax Tree of the file. You can think of it as parsing the code. This operation is also done in compilers, which then look for import statements recursively to generate a graph of dependencies.

It then converts the files into [IIFEs](https://developer.mozilla.org/en-US/docs/Glossary/IIFE#:~:text=An%20IIFE%20(Immediately%20Invoked%20Function,soon%20as%20it%20is%20defined.) to modularize them (remember, putting code inside a function restricts its scope). By doing this, they modularize the files and make sure the variables and functions are not accessible to other files.

Without this operation, it would be like copying and pasting the code of the imported file and that file would have the same scope.

Webpack does many other advanced things behind the scenes, but this is enough to understand the basics.

Bonus – ESLint

Code quality is important and helps keep your projects maintainable and easily extendable. While most of us developers recognize the significance of clean coding, we sometimes tend to ignore the long term consequences under the pressure of deadlines.

Many companies decide on coding standards and encourage developers to obey those standards. But how can you make sure that your code meets the standards?

Well, you can use a tool like ESLint to enforce rules in the code. For example, you can create a rule to enforce or disallow the usage of semicolons in your JavaScript code. If you break a rule, ESLint shows an error and the code does not even get compiled – so it is not possible to ignore that unless you disable the rule.

Linters can be used to enforce standards by writing custom rules. But you can also use the pre-made ESLint configs established by big tech companies to help devs get into the habit of writing clean code.

You can take a look at Google's ESLint config here – it is the one I prefer.

ESLint helps you get used to best practices, but that's not its only benefit. ESLint also warns you about possible bugs/errors in your code so you can avoid common mistakes.

Bonus – CI/CD (CircleCI)

Continuous Integration/Development has gained a lot of popularity in recent years as many companies have adopted Agile principles.

Tools like Jenkins and CircleCI allow you to automate the deployment and testing of your software so you can deploy more often and reliably without going through difficult and error-prone build processes by yourselves.

I mention CircleCI as the product here because it is free and used frequently in JavaScript projects. It's also quite easy to use.

Let's go over an example: Say you have a deployment/QA server and your Git repository. You want to deploy your changes to your deployment/QA server, so here is an example process:

1. Push the changes to Git
2. Connect to the server
3. Create a Docker container and run it
4. Pull the changes to the server, download all the dependencies (npm install)
5. Run the tests to make sure nothing is broken
6. Use a tool like ESLint/Sonar to ensure code quality
7. Merge the code if everything is fine

With the help of CircleCI, you can automatically do all these operations. You can set it up and configure to do all of the above operations whenever you push a change to Git. It will reject the push if anything goes wrong, for example a failing test.

I will not get into the details of how to configure CircleCI because this article is more about the "Why?" of each tool. But if you are interested in learning more and seeing it in action, you can check out this tutorial series.

Conclusion

The world of JavaScript is evolving rapidly and new tools are gaining popularity every year.

It's easy to react to this change by just learning how to use the tool – we are often too busy to take our time and think about the reason why that tool became popular or what problem it solves.

In this article, I picked the tools I think are most popular and shared my thoughts on their significance. I also wanted to make you think about the problems they solve rather than just the details of how to use them.

If you liked the article you can check out and subscribe to my blog where I try to write frequently. Also, let me know what you think by commenting so we can brainstorm or you can tell me what other tools you love to use :)

ESLint is a powerful tool that helps you enforce consistent coding conventions and ensure quality in your JavaScript codebase.

Coding conventions are sometimes difficult to decide on, and having a tool that automates their enforcement helps avoid unnecessary discussions. Ensuring quality is also a welcome feature: linters are excellent tools for catching bugs, such as those related to variable scope.

ESLint is designed to be completely configurable, giving you the option of enabling/disabling each rule, or mixing the rules to match your needs.

With this in mind, the JavaScript community and companies who use JavaScript can extend the original ESLint config. There are several examples in the npm registry: eslint-config-airbnb is one of the most well-known.

In your daily routine, you will probably combine more than one config, since there is no one-config-fits-all. This post will show how to create your own repository of configurations, giving you the option to centralize all your rule definitions.

Create the project

First you'll need to create a new folder and npm project. By convention, the module name begins with eslint-config-, such as eslint-config-test.

mkdir eslint-config-test
cd eslint-config-test
npm init

You will have a package.json file that will look like the following snippet:

{
  "name": "eslint-config-test",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "",
  "license": "ISC"
}

Next, it's time to add your ESLint dependencies:

npm install -D eslint eslint-config-airbnb eslint-config-prettier eslint-plugin-import eslint-plugin-jsx eslint-plugin-prettier eslint-plugin-react eslint-plugin-react-hooks prettier

The packages will change according to your needs. In this case, I work with React codebases and I use Prettier to format my code. The documentation mentions that if your shareable config depends on a plugin, you should also specify it as a peerDependency.

Next, I will create a .eslintrc.js with my configuration - this is similar to what you already do in your apps:

module.exports = {
  extends: [
    'airbnb',
    'eslint:recommended',
    'plugin:import/errors',
    'plugin:react/recommended',
    'plugin:jsx-a11y/recommended',
    'plugin:prettier/recommended',
    'prettier/react',
  ],
  plugins: [
    'react-hooks',
  ],
  rules: {
  },
};

The rules object stores any rule that you want to override. In the snippet above rules is empty but feel free to check my overrides. In the Airbnb/JavaScript repository you can find a list of overridden rules by the community.

Create custom rules

Time to create a .prettierrc with your custom rules - this is a tricky part since Prettier and ESLint can conflict on a few rules:

{
  "tabWidth": 2
}

It is important to mention that the .prettierrc file should live in the root of the project that is using your package. Right now, I am manually copying it.

The next step is to export your config in the index.js file:

const eslintrc = require('./.eslintrc.js');

module.exports = eslintrc;

It is technically possible to create all configurations in the index.js file. But if you do this, you won't get the config object linted (insert your Inception joke here).

You're done!

Voilà! That’s all you need to start your own package of configurations. You can test locally your config package by running the following in a JavaScript project:

npm install /Users/leonardo/path/to/eslint-config-test

Keep in mind that the dependencies of your configuration package may also be installed.

If everything looks fine, you can publish to the npm registry:

npm publish

Full example

I have a functional GitHub project showing the setup of this post: eslint-config-leozera. You can also see it below:

More about the project

• Configuring ESLint: official ESLint docs. You know, read the docs
• How to publish your first NPM package: quoting the post subtitle – "everything you need to know to create a NPM package."
• eslint-config-wesbos: a project by Wes Bos that helped me while doing this work

Also posted on my blog. If you like this content, follow me on Twitter and GitHub. Cover photo by Susan Holt Simpson/Unsplash.

Previously I wrote about linting, what it is, and how it makes your life easier. At the end, I actually included a way that you could automatically fix your code. So why am I writing this?

What do you mean fix it?

Before we roll into it, let’s hit this quick. Linters are powerful and provide an easy way to scan your code for syntax errors that could lead to bugs. Or they can simply help keep a codebase clean, healthy, and consistent. When run, it will show all the issues and let you go through each one individually to fix them.

Taking that to the next level, some linters will actually allow you to pass in an argument to the command running the linter that allows it to fix it for you automagically. This means you don’t have to manually go through and make all of those little whitespace and semicolon (add them! ?) tweaks yourself!

Ron Swanson happy

So what more can I do to fix things?

If you already use the fix option, thats a good start. But there are tools out there that have been developed specifically to tackle this problem beyond just a flag into your command. The one I’m going to cover is Prettier.

What is Prettier?

Prettier pegs itself as “an opinionated code formatter." It takes an input of your code and outputs it in a consistent format stripping any of the original code style. It actually converts your code to a syntax tree, then rewrites it using the styles and rules you and Prettier provide together via your ESLint config and Prettier’s default rules.

You can easily use Prettier alone just to format your code, which works just fine. But if you combine this with an underlying ESLint process, you get both a powerful linter and a powerful fixer. I’m going to show you how to make those work together.

Voltron

Getting started with Prettier

For this walkthrough, I’m going to assume that you have ESLint set up and configured in an application. Particularly, I’m going to pick up where I left off in my previous walkthrough where we installed ESLint to a React application.

Additionally of note, Prettier tells us right from the start that it's an opinionated code formatter. You should expect that it will format your code in a consistent way, but maybe a different way than you currently have it configured. But don’t fret! You can tweak this configuration.

So what are we starting off with? We already:

• Have installed ESLint
• Have added Babel as our parser
• Have added a plugin that includes React configurations

Next, let’s get started by installing a few packages:

yarn add prettier prettier-eslint prettier-eslint-cli -D

Note: the command above is similar to using npm. If your project doesn't use yarn, swap out to npm as appropriate.

Above, we’re installing:

• prettier: core Prettier package and engine
• prettier-lint: passes the Prettier result to ESLint to fix using your ESLint config
• prettier-eslint-cli: helps Prettier and ESLint work together on various files across your project

And we’re installing them as a dev dependency, as we don’t need it outside development.

Configuring your new formatter

Now that our packages are installed, we can set up yarn to run this command for us.

Previously, we set up a lint script to look like this in our package.json:

"scripts": {
  ...
  "lint": "eslint . --ext .js"
  ...
}

We’re going to leave that as it is, but we’ll do something similar and create a new script right next to it called format for our formatter Prettier:

"scripts": {
  ...
  "format": "prettier-eslint --eslint-config-path ./.eslintrc.js --write '**/*.js'",
  "lint": "eslint . --ext .js"
  ...
}

So what’s going on there? We’re:

• Adding a new script called format, that we can run as yarn format
• We’re utilizing our prettier-eslint-cli package to run the formatting for us
• We’re passing in our ESLint config located next to our package.json in the root of the project (change this if it’s in a different location)
• And finally, we’re telling prettier to write all files matching **/*.js, or any JS files it finds recursively through our project

The beauty here is that we're passing in our ESLint config to Prettier. This means we only have to maintain 1 config for both tools, but we still leverage the linting power of ESLint along with the formatting power of Prettier.

Run your formatter!

Now that we’re all set up, let’s run it! Run this following:

yarn format

and immediately, we see that it works:

Successfully running Prettier

Hey, my code looks different!

Angry mob with pitchforks

As I mentioned earlier, Prettier tells us straight up, it’s an opinionated formatter. It ships with its own rules, sort of like its own ESLint config, so it will go through and make those changes as well.

Don’t abandon your code! Instead, you can review the changes, see if maybe it makes sense to keep it that way (it will be very consistent) or you can update your ESLint config (.eslintrc.js) to overwrite the rules you don’t like. This is also a good way to maybe learn some new things that you might not have expected to get caught before.

So where does this leave us?

If you’ve followed along so far, we now have two commands:

• lint: which will check your code for you and tell you what's wrong
• format: will automatically try to fix the problems for you

When using these in practice, your best bet is to always run format first to let it try to automatically fix anything it can. Then immediately run lint to catch anything Prettier wasn’t able to fix automatically.

What’s next?

Now that we can format our code automatically, we should be able to fix our code automatically!

Eddie from Fresh Off the Boat's mind blown

Next time we’ll take this a step further and set up a git hook that will allow this to run before you commit. This means you won't ever have to worry about forgetting to run this again!

Originally published at https://www.colbyfayock.com/2019/11/dont-just-lint-your-code-fix-it-with-prettier/

So what is linting?

lint, or a linter, is a tool that analyzes source code to flag programming errors, bugs, stylistic errors, and suspicious constructs. https://en.wikipedia.org/wiki/Lint(software)

Simply put, a linter is a tool that programmatically scans your code with the goal of finding issues that can lead to bugs or inconsistencies with code health and style. Some can even help fix them for you!

Michael Scott - Tell me more

Take for instance, the following example:

const test = 'I am a test';
console.log(`Test: ${test}`);
const test = 'Another one.';

We’re declaring the constant test twice, which our javascript engine won’t be happy about. With the proper linter settings and watch configuration, instead of getting caught later as an error when the code runs, you’ll immediately get an error through your linter running in the background:

  10:9  error  Parsing error: Identifier 'test' has already been declared

   8 |   const test = 'I am a test';
   9 |   console.log(`Test: ${2}`);
> 10 |   const test = 'Another one.';
     |         ^

It might be pretty obvious that you have 2 of the same const declarations given this is only 3 lines, but in a more complex application, this can save tons of time having to hunt down a pesky bug that’s not always obvious.

What all can linting help with?

Lots of things, including but not limited to:

• Flagging bugs in your code from syntax errors
• Giving you warnings when code may not be intuitive
• Providing suggestions for common best practices
• Keeping track of TODO’s and FIXME’s
• Keeping a consistent code style

Most things you can think of probably already exist in one form or another, and if not, you can even create custom rules that fit your needs!

How is this actually helping or why should I care?

Probably the biggest overlying theme of the list above is the fact that these issues will be called out immediately. No longer will these issues creep up on you in the middle of running your app or give someone anxiety during a code review. No longer will you and your reviewer endlessly fight passive aggressively through the comments about whether or not to include a semicolon at the end of JS statements (you should ?).

Grandma looking for a semicolon

All of those moments that stop you from being productive because of a silly syntax error or the micro-interactions you and your teammates have during a review take time. They add up and end up taking away the time you can spend fixing another bug or developing the next great feature of your product.

So how do I actually get started?

Even though there are linters for most, if not all, other mainstream languages, for the purpose of this post, I’m going to focus on Javascript. The same principles apply, but the tooling may be a bit different.

I’m going to run through how you can get set up for basic linting in a React app. You can easily follow along by spinning up your own React app or using my Gatsby starter: https://github.com/colbyfayock/gatsby-starter-sass#starting-from-scratch

Your Linter

To get started, we first need a linter. Probably the most popular in the Javascript world is ESLint. Your linter will actually be the engine for defining rules and parsing your files to test against. ESLint is available as an npm package by itself and once installed, out of the box it allows you to set up a basic configuration file and hit the ground running with some command line tools.

Let’s first add our ESLint dependency:

yarn add eslint -D

We’re installing this as a devDependency (hence the -D flag), because this isn’t something our application needs to run. After it’s successfully installed, let’s add it to our package.json as a script:

...
"scripts": {
  ...
  "lint": "eslint .  --ext .js"
  ...
},
...

In the above, we’re running our linter on the entire project directory on any file that has an extension of .js. If you're working with a large project with many file types, maybe even some you don't want linted, you can change that flag or be more specific with other options.

To support ESLint, we’ll need to do one more thing. Let’s add a file at the root of our project (probably where your package.json is) called .eslintrc.js and make the contents of the file simply:

module.exports = {};

Once you’re ready, you can run yarn lint and… get an error.

Lint results - Import errors

This is okay, and expected in our project, so let’s move on.

Your Parser

A common tool in the chain for Javascript developers is Babel, which allows you to write code with features that may not be supported in all browsers, such as using arrow functions, that are available in ES6, and other conventions like importing files via import.

The code you write may already run through Babel to work in a browser, but that doesn’t apply to ESLint by default, so ESLint allows you to specify a parser that allows the linting processing to look at the same code as your browser sees. In this case we’ll want to use Babel’s ESLint parser that’s made available to us.

To set that up, we’ll want to first install our dependency:

yarn add babel-eslint -D

Typically if you're using babel-eslint you'll want to make sure babel is installed next to it, but in our case, Gatsby already uses babel, so we don’t necessarily need to add it. After that’s set up, we’ll want to update our .eslintrc.js config file with some new options:

module.exports = {
    "env": {
        "browser": true,
        "node": true,
        "es6": true
    },
    "parser": "babel-eslint"
};

Here, we’re letting ESLint know that our environment will be run in node (Gatsby’s precompiling), inside the browser (the app), and it will use ES6. This helps ESLint know how to run your code. Additionally, we want to set up our parser to be babel-eslint.

Once we’re ready to go, run yarn lint again and… well nothing really happened.

Lint results - Nothing happened

This is still expected, as we don’t have any rules set up!

Plugins for your code

Writing a React app? The Babel parser may help you transform your code, but you might have a hard time being productive, as ESLint needs to understand how it should work to lint your React files.

Part of the beauty of ESLint is that it allows you to configure plugins that have the opportunity to create and set rules for you. Luckily, along with our Babel parser above that does some of the heavy lifting, we have a React plugin available that does just that and takes care of linting the JSX for us.

Let’s first install our dependency:

yarn add eslint-plugin-react -D

Further, let’s update our .eslintrc.js file again:

module.exports = {
    "settings": {
        "react": {
            "version": "detect"
        }
    },
    "env": {
        "browser": true,
        "node": true,
        "es6": true
    },
    "plugins": [
        "react"
    ],
    "parser": "babel-eslint"
};

What we’re adding here is a setting that automatically detects what React version you’re using, which is helpful to let your linting get parsed properly, and then set up our react plugin that we installed above.

For one last final time, we will run our lint script and get nothing:

Lint results - Nothing happened

Rules defined by others’s opinions

If you’re not really sure where to get started or just want to quickly get up and running, it’s recommend that you enable ESLint’s own recommended rules. Let’s add this to our .eslintrc.js config file:

module.exports = {
    "settings": {
        "react": {
            "version": "detect"
        }
    },
    "env": {
        "browser": true,
        "node": true,
        "es6": true
    },
    "plugins": [
        "react"
    ],
    "extends": [
        "eslint:recommended"
    ],
    "parser": "babel-eslint"
};

And let’s run our yarn lint.

Woah! This will immediately give you a lot errors, it seems like something’s wrong.

Lint results - React errors

Since we’re running a React app, we also want to make sure our linter understands the rules it should follow, so let’s also add our React plugin to the .eslintrc.js config setup:

    "extends": [
        "eslint:recommended",
        "plugin:react/recommended"
    ],

Now if you run yarn lint, you get something a little more logical.

Lint results - Normal errors

If you’re following along, it looks like our starter app had a misplaced semicolon and a missing prop in our propTypes validation for Layout.js. Writing this helped me fix my own repo! ?

Going further, if those don’t seem to fit your needs, lots of developers and teams have published their own configurations that ESLint allows you to easily tap into.

Some popular ones include:

• Airbnb’s config
• Semistandard
• Google’s JS Style Guide

Not happy with the options available? You can even create and publish your own to either layer on top of others as a starting point or give it a go from scratch.

Let it do the work (most of it)

You don’t think I’m going to make you fix all of those thing yourself do you? Well, you may have to fix some, but let’s try to get ESLint to fix some of it for us.

If you noticed after we ran the command above, ESLint gave us an extra message:

Lint results - Option to fix

So let’s give it a try! Let’s run:

yarn lint --fix

And what do you know, it now only gives us 1 linting error.

Lint results - 1 error

Turns out ESLint was able to fix our semicolon issue automatically, but we’ll still have to add pageName to our Layout’s propTypes manually, not too much of a lift.

Running one more time and finally nothing again! But this time because everything's looking good.

Lint results - No errors

Go forth and write messy code!

Bruce Almighty - Typing

Kidding ? The good news here, is now you can easily take a look at the general health of your codebase as well as hopefully fix most of it automatically. This is going to save a lot of headaches as you work with others on your team, and generally, it’s nice to have all of your code neat and tidy.

This post is just getting started. ESLint is a wide open book with tons of plugins and rules, and it’s not the only linting tool in the game. Play around and find what fits best for you and your team. The little time spent configuring it to your app will save you lots more time in the long run.

Other linting tools to check out

• JSHint: an alternative to ESLint
• Stylelint: a linting tool for CSS and CSS-like syntaxes like Sass
• Awesome ESLint: a simple list of awesome configs, parsers, plugins, and other tools to boost your ESLint game
• Webhint: linting tool for accessibility, speed, and more website best practices
• A11y JSX Plugin: ESLint plugin for checking accessibility rules on JSX elements

Originally published at https://www.colbyfayock.com/2019/10/what-is-linting-and-how-can-it-save-you-time

Recently, I've been getting more involved in front-end development. The more I do, the more my mind and my soul get lost in its chaotic world. Even a simple To–Do–List app can easily require a bunch of tools—ESLint, Babel, Webpack, to name a few—and packages just to get started.

Fortunately, there’re many starter kits out there so we don’t have to do everything from the ground up. With them, everything is already set up so we can start writing the first line of code right away. It saves time on repetitive, boring tasks, which can be great for experienced developers.

However, this benefit comes with a price for beginners. Since everything works out of the box, it seems like magic, and they might not know what's really happening under the hood, which is important to understand at some level. Although the learning curve is not as steep as others—try to compare with some tools you've been learning and using, you'll get what I mean—in this chaotic world, we need a survival guide for the journey.

This series will cover fundamental tools of front-end development and what essentials we need to know about them. This will allow us to rule the tools instead of being controlled by them.

In it, we’ll focus on the developer experience of each one of these tools. So the goal of this series is to act as a survival guide and to give a high-level overview of each tool, not to serve as documentation.

What will be included:

• ESLint <- We are here
• Babel
• Webpack
• Flow
• TypesScript
• Jest.

Enough of a preface, let's get started with the first tool: ESLint.

What is ESLint and Why should we use it?

ESLint is, as the name implies, a linter for ECMAScript. And, the definition of a linter is:

a machine for removing the short fibers from cotton seeds after ginning.

Although code and cotton seeds don't have any relationship, regardless of code or cotton seeds, a linter will help make things cleaner and more consistent. We don't want to see the code like this:

const count = 1;
const message  =  "Hello, ESLint"
    count += 1

It both looks ugly and has a mistake. Here's when ESLint steps in to help with that. Instead of letting the error be dumped out to the browser console when we run the code, ESLint will catch it as we're typing (well not really: we’ll need editor or IDE extensions for this, which will be covered later).

Of course, this error isn't difficult to figure out, but wouldn't it be nicer to have an assistant reminding us every time we're about to make a mistake and perhaps auto-correcting it for us? Although ESLint can’t catch all kinds of errors, it at least spares us some effort so we can spend time on other things that matter and need human attention.

How does ESLint work?

Now that we know what ESLint is and why we need it, let's go a bit deeper and check out how it works. In essence, we can break it down to three big steps.

Parser

The code that we write is nothing more than a sequence of characters. However, this sequence isn't just random characters: they need to follow a set of rules or conventions that is the grammar forming a language.

For a human, going from reading text or code to understanding it conceptually takes us little effort. For a computer, this is much more difficult to accomplish. For example:

const tool = 'ESLint' // 1
  const  tool  =  "ESLint" // 2

As we read the two lines above, we immediately know that they are identical, and can be read as "there's a constant named tool with the value of ESLint". For a computer, which doesn't understand the meaning, these two lines look quite different. As a result, if we feed in raw code to ESLint, it's nearly impossible to do anything.

When things get complicated and hard to communicate—think of how we can have a computer to understand what we do—abstraction can be an escape. By abstracting a thing, we hide all unnecessary details, reduce noise, and keep everyone on the same page, which eases the communication. In the above example, one space or two spaces don’t matter, neither do single quotes or double quotes.

In other words, that's what a parser does. It converts raw code to an Abstract Syntax Tree (AST), and this AST is used as the medium for lint rules to base on. There are still many steps a parser need to do in order to create an AST—if you're interested in learning more about how an AST is generated, this tutorial has a good overview.

Rules

The next step in the process is to run the AST through a list of rules. A rule is a logic of how to figure out potential existing issues in the code from the AST. Issues here aren't necessarily syntactic or semantic errors, but might be stylistic ones as well. The output given out from a rule will include some useful information for later use like lines of code, positions, and informative messages about the issue.

In addition to catching issues, a rule can even auto-correct code if possible. For example, when no-multi-spaces is applied to the code above, it will trim all redundant spaces, which makes the code look clean and consistent.

  const  tool  =  "ESLint" // 2
// becomes
const tool = "ESLint" // 2

In different scenarios, a rule can be used at different levels—opted-out, warning only, or strict error—and have various options, which gives us control on how to use the rule.

Result

Here comes the end of the process. With the output from a rule, it's just the matter of how we display it in a human friendly manner, thanks to all the useful information we mentioned earlier. Then from the result, we can quickly point out the issue, where it is, and make a fix, or maybe not.

Integration

ESLint can be used as a standalone tool with its robust CLI, but that’s a bare-bones way to use ESLint. We don't want to type in a command every time we want to lint code, especially in a development environment. The solution for this is to integrate ESLint into our development environment so we can write code and see issues caught by ESLint all in one place.

This kind of integration comes from extensions specific to IDEs or editors. These extensions require ESLint to work since they run ESLint behind the scene—no wonder that we still need to install ESLint along with them, they are nothing without ESLint. This principle applies to other IDE or editor extensions we are using daily.

Remember the output from a rule we talked above? An extension will use it to display in the IDE or editor. How exactly the output is displayed depends on how the extension is implemented and how the IDE or editor is open to its extensions. Some extensions also take advantage of the abilities of issue correction from rules to change code on save if we enable it.

Configuration

Configuration is the main power that gives versatility to a tool. ESLint is not different from that, except it has the most comprehensive configuration among other tools. In general, we need a file or a place to put the configuration, and there's a couple of options of us.

All of them boil down to two main ways: either we have a separate configuration file for each tool, or we bundle them all in package.json. .eslintrc.js is one of the files that ESLint will be looking for its configuration, and also the one with the highest priority.

The next thing we need to know about configuration is its hierarchy and cascading behavior. Thanks to these features, we don't need to have a configuration file in every single folder in the project.

If a configuration file doesn't exist in a folder, ESLint simply looks up the folder's parent for one until it can't find one. Then it'll fall back to the user–wide default configuration in ~/.eslintrc. Otherwise, the configuration file will add up or override the ones at upper levels.

There is, however, a special tweak on this. If we specify root: true in a configuration file, the lookup will stop at that file instead of going up like before. Besides, ESLint will use that configuration file as the root configuration, and all child configurations will be based on this one.

This is not only limited to ESLint - these things are common for other tools. Let's talk about ESLint specific configuration.

Parser

The role of the parser in ESLint has been discussed above. By default, ESLint uses Espree as its parser. We can change this parser to another compatible one like babel-eslint or @typescript-eslint/parser if we use Babel or Typescript, respectively.

To configure the parser, we use parserOptions. Among options supported by Espree, here are some we often use and need to pay attention to:

• ecmaVersion

We need to specify the appropriate ECMA version to features we want to use. For example, if emcaVersion: 5, the code below will give some errors.

```javascript
let a = [1, 2, 3, 4] // error due to `let` keyword
var b = [...a, 5] // error due to spread syntax

The parser can't parse the code because both the `let` keyword and spread syntax were just introduced in ES6. Changing `emcaVersion` to 6 or above will simply resolve the errors.

* `sourceType`

Nowadays, we mostly write everything in modules, then bundle them together. So this option, most of the time, should be `module`. 

Another value we can use—as well as the default—is `script`. The difference is whether we can use [JS modules](https://v8.dev/features/modules) or not, i.e., use `import` and `export` keyword. The next time we get this error message `Parsing error: 'import' and 'export' may appear only with 'sourceType: module'`, we know where to look.

* `ecmaFeatures.jsx`

There might be additional ES features we want to use, for example [JSX](https://facebook.github.io/jsx/) syntax. We use `ecmaFeatures.jsx: true` to enable this feature. Note that, JSX support from Espree isn't the same as JSX in React. If we want React specific JSX, we should use [eslint-plugin-react](https://github.com/yannickcr/eslint-plugin-react) for better results.

If we use another parser, these options are more or less the same. Some might have fewer options, and others might have more, but they're all defined under `parserOptions`.

## Environment

It depends on where the code is running: there are different predefined global variables. We have `window`, `document` in the browser, for example. It would be irritating if the [no-undef](https://eslint.org/docs/rules/no-undef) rule is enabled, and ESLint keeps telling us `window` or `document` is not defined.

The `env` option is here to help. By specifying a list of environments, ESLint will know about global variables in these environments, and let us use them without a word.

There's a special environment we need to note, `es6`. It'll implicitly set `parserOptions.ecmaVersion` to 6, and enable all ES6 features except for modules which we still need to use `parserOptions.sourceType: "module"` separately.

# Plugins and Shareable Configs

Having the same configuration for rules over and over again across different projects might be tiresome. Luckily, we can reuse a configuration, and only override rules as needed with `extends`. We call this type of config shareable configs, and ESLint already has two for us: `eslint:recommended` and `eslint:all`. 

Conventionally, ESLint's shareable configs have `eslint-config` prefix so we can easily find them via NPM with [`eslint-config`](https://www.npmjs.com/search?q=keywords:eslint-config) keyword. Among hundreds of results, there're some popular ones, like [eslint-config-airbnb](https://github.com/airbnb/javascript/tree/master/packages/eslint-config-airbnb) or [eslint-config-google](https://github.com/google/eslint-config-google), you name it.

Out of the box, ESLint has a bunch of rules to serve different purposes from possible errors, best practices, ES6 to stylistic issues. Moreover, to supercharge its ability, ESLint has a great number of 3rd-party rules provided by almost a thousand plugins. Similar to shareable configs, ESLint's plugins are prefixed with `eslint-plugin`, and are available on NPM with the [`eslint-plugin`](https://www.npmjs.com/search?q=keywords:eslint-plugin) keyword.

A plugin defines a set of new rules, and in most cases it exposes its own handy configs. For example, the [eslint-plugin-react](https://github.com/yannickcr/eslint-plugin-react) gives us two shareable configs, `eslint-plugin-react:recommended` and `eslint-plugin-react:all` just like `eslint:recommended` and `eslint:all`. To use one of them, we need to, firstly, define the plugin name, and secondly extend the config.

```javascript
{
  plugins: ["react"],
  extends: "plugin:react/recommended"
}

// Note that we need to prefix the config by `plugin:react`

One common question to ask is what plugins or configs to use. While it largely depends on our needs, we can use Awesome ESLint as a reference to find useful plugins as well as configs.

Prettier

We're almost there - we've almost gotten to the end. Last but not least, we'll discuss a popular pair of ESLint, Prettier. In short, Prettier is an opinionated code formatter. Though Prettier can be used alone, integrating it to ESLint enhances the experience a lot, and eslint-plugin-prettier does this job.

The difference between using Prettier alone and using Prettier with ESLint can be summarized to code formatting as an issue. Instead of giving format issues separately, running Prettier with ESLint will treat format issues just like other issues. However, these issues are always fixable, which is equivalent to formatting the code.

That's how eslint-plugin-prettier works. It runs Prettier, as a rule, behind the scene and compares the code before and after being run through Prettier. Finally, it reports differences as individual ESLint issues. To fix these issues, the plugin simply uses the formatted code from Prettier.

To have this integration, we need to install both prettier and eslint-plugin-prettier. eslint-plugin-prettier also comes with eslint-plugin-prettier:recommended config—which extends eslint-config-prettier. Therefore we also need to install eslint-config-prettier to use it.

{
  "plugins": ["prettier"],
  "extends": "plugin:prettier/recommended"
}

Conclusion

Code linters or formatters have become the de facto standard in software development in general, and ESLint, specifically, in front-end development.

Its benefits go far beyond what it does technically, as it helps developers focus on more important matters. Thanks to delegating code styling to a machine, we can avoid opinionated styles on code review, and use that time instead for more meaningful code review. Code quality also benefits, and we get more consistent and less error-prone code.

This article was originally posted at my blog.

or How to never worry about code styling again

_Photo by [Unsplash](https://unsplash.com/photos/bJjsKbToY34?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText" rel="noopener" target="_blank" title="">NordWood Themes on <a href="https://unsplash.com/search/photos/computer?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText" rel="noopener" target="blank" title=")

ESLint and stylelint are really amazing tools that allow you to enforce coding patterns among your teams. This has many benefits, like outputting better and more consistent code, getting rid of useless diffs in commits (newline, indentation, et al.) among many others.

But over time, this can prove to be a bit of a hassle among the developers of a team, who find it an extra mental burden to manually add semicolons, newlines, indentations, etc just to conform to the lint rules. This is where a code formatting tool like Prettier comes in.

Prettier can be set up to automatically format your code according to some specified rules. If you are using VSCode, you can even have your code be formatted whenever you hit save (I’m sure there must ways to set this up in other editors but I haven’t looked into it.)

However, you don’t want to create a new Prettier config file, since you already have all the formatting related rules specified in your ESLint and stylelint config files. So, we will need some magic for that. ✨

Let’s now dive into a step by step of how to set this all this up, and also how to format all of your existing code according to the lint rules. This guide assumes that your project already has ESLint and stylelint set up with their .eslintrc and .stylelintrc files.

PART 1: Formatting the existing codebase

Step 1

Install prettier-eslint, which is a tool that formats your JavaScript using Prettier followed by eslint --fix. The --fix is an ESLint feature that attempts to automatically fix some problems for you.

npm install --save-dev prettier-eslint

This tool infers the equivalent Prettier config options from your existing .eslintrc file. So you shouldn’t need to create a new .prettierrc file in most cases.

Step 2

Install prettier-eslint-cli. This is the CLI tool that’ll help you run all of your files through prettier-eslint at once.

npm install --save-dev prettier-eslint-cli

Step 3

Install prettier-stylelint, which is a tool that formats your CSS/SCSS with Prettier followed by stylelint —-fix. Like ESLint, --fix is a stylelint feature that attempts to automatically fix some problems for you.

npm install prettier-stylelint --save-dev

This tool also attempts to create a Prettier config based on the stylelint config.

Note that unlike prettier-eslint, you don’t have to install another package for its CLI since that is already included in it.

Step 4

Write scripts inside your package.json targeting the existing files in your codebase that you wish to run through prettier-eslint and prettier-stylelint.

"scripts": {

  "fix-code": "prettier-eslint --write 'src/**/*.{js,jsx}' ",

  "fix-styles": "prettier-stylelint --write 'src/**/*.{css,scss}' "

}

As you can see, I am targeting all of my existing JS and JSX and all of my existing CSS and SCSS, respectively.

The --write flag writes the changes in-place for the file currently being formatted. So, be careful and make sure that all of your existing files are under source control and that there are no uncommited changed.

Step 5

Run the scripts!

npm run fix-codenpm run fix-styles

Now, you can check-in all of these new changes as a single big commit (maybe even from a temporary git user, if you don’t wanna pollute your own git history.)

Part 2: Setting up VSCode

Now that your existing codebase is formatted, its time to make sure that all the code being written henceforth is formatted automatically.

Step 1

Install the Prettier, ESLint, and stylelint extensions for VSCode:

Prettier - Code formatter - Visual Studio Marketplace
_Extension for Visual Studio Code - VS Code plugin for prettier/prettier_marketplace.visualstudio.comESLint - Visual Studio Marketplace
_Extension for Visual Studio Code - Integrates ESLint JavaScript into VS Code._marketplace.visualstudio.comstylelint - Visual Studio Marketplace
_Extension for Visual Studio Code - Modern CSS/SCSS/Less linter_marketplace.visualstudio.com

Step 2

Configure a few VSCode settings:

"prettier.eslintIntegration": true — tells Prettier to use prettier-eslint instead of Prettier

"prettier.stylelintIntegration": true — tells Prettier to use prettier-stylelint instead of Prettier

"eslint.autoFixOnSave": false — we don’t need ESLint to fix our code for us directly, since prettier-eslint will be running eslint --fix for us anyways.

"editor.formatOnSave": true — runs Prettier with the above options on every file save, so you never have to manually invoke VSCode’s format command.

Additionally, you can check-in the above workplace settings to source control so its easier for other team members to set up their editors. You can do so by creating a .vscode folder at the root of your project and putting all of the above rules in a settings.json file.

Optionally, you can tell Prettier to ignore formatting certain patterns of files. To do this, just add a .prettierignore file to the root of your project specifying the paths to ignore. For instance:

strings.jsonscripts/*

And that’s it! Never worry about code styling again ?

This article is by no means intended to be an exhaustive guide, but rather an introduction to what is possible with the amazing tools mentioned herein. I recommend opening up the official GitHub pages for each to learn more about how to utilise these tools more effectively for your specific workflow.

Please write a comment below for any help, suggestion, etc.

References

https://prettier.io/docs/en/
https://stylelint.io/user-guide/
https://eslint.org/
https://github.com/prettier/prettier-vscode
https://github.com/prettier/prettier-eslint
https://github.com/prettier/prettier-eslint-cli
https://github.com/hugomrdias/prettier-stylelint
https://www.youtube.com/watch?v=YIvjKId9m2c

tl;dr Run yarn add --dev eslint-plugin-import and add "import/named": 2 to your .eslintrc rules to prevent accidentally importing constants that don’t exist to your reducers.

If you’re developing an application using React and Redux, your reducers probably look something like this:

This example is pretty straight-forward. You’re only importing one constant up top.

Your file structure currently looks like this:

.├── actions|   ├── constants.js|   └── index.js...omitted for brevity...├── reducers|   ├── accountReducer.js|   └── index.js...omitted for brevity...├── indes.js└── index.html

But as your codebase grows, your reducers will become more complicated. Organizing your files by type may no longer makes sense. So you decide to start organizing things by feature or route instead:

.├── actions|   ├── constants.js|   └── index.js...omitted for brevity...├── reducers|   └── index.js├── routes|   ├── accounts|   |   ├── components|   |   ├── containers|   |   ├── module|   |   |   ├── actions.js|   |   |   ├── constants.js|   |   |   └── index.js (exports our reducer)|   |   ├── styles|   |   └── index.js|   └── index.js...omitted for brevity...├── indes.js└── index.html

Awesome! Now you don’t have 100 components in our main components folder anymore. Things are a bit neater, and easier to reason about.

There’s a problem with your refactor, though. Suddenly this import in your reducer is now referring to a non-existent path:

import { RECEIVE_ACCOUNT_SUCCESS } from '../actions/constants';

You get an error about that path being unresolved immediately, so you change it:

import { RECEIVE_ACCOUNT_SUCCESS } from './constants';

Cool. But what if you didn’t actually define that constant in your new file?

Now you’re about to experience one of the most frustrating bugs possible in a Redux app — importing an undefined constant into a reducer. Your tests will break, your app will break, and you’ll bash your head into your desk until you figure it out.

The problem is that this type of bug just fails silently. ES6 imports don’t care whether or not the variable you’re importing is defined. You’ll never see an error about it.

ESLint to the Rescue!

The key to avoiding this type of bug is to installing eslint-plugin-import, then set one simple little rule in your .eslintrc:

"import/named": 2

That’s it! Now you’ll get an error anytime you try to import an undefined constant into one of your reducers.

Edit: Unless you’re extending a base config that already includes it, you’ll also need to add "import" to the plugins section of your .eslintrc. Thanks to Dave Mac for pointing that out!

Happy coding!