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.

But when a project is managed by multiple developers, the focus shifts into consistency especially in terms of written code.

Keeping a consistent code style and formatting across many team members and project is a challenging task. It's almost impossible to do it manually, but that's where Prettier comes into play.

In this guide, you will learn how to install Prettier in Visual Studio Code and how to use it to format code.

Prerequisites

Before you follow this guide, you will need to download and install Visual Studio Code.

What is Prettier?

Prettier is a powerful code formatter that automates this process from start to finish. It gives you confidence that your code adheres to defined coding standards without any manual actions (unless you want to have it manual).

Prettier not only supports all JavaScript libraries and frameworks, such as Angular, React, Vue, and Svelte, but also works with TypeScript.

That's why it is used by many people in tech worldwide.

How To Install Prettier in Visual Studio Code

To install Prettier in Visual Studio Code, you need to:

1. Open the Extensions tab.
2. Type prettier in the search box.

Visual Studio Code / Extensions

At the top of the list you will find the Prettier - Code formatter extension. You need to open it, and click the Install button:

Visual Studio Code / Extensions / Prettier - Code Formatter

After the successful installation you will see the text saying "This extension is enabled globally":

Visual Studio Code / Extensions / Prettier - Code Formatter (Installation completed)

How To Activate Prettier in Visual Studio Code

When your Prettier extension is installed, you need to configure Visual Studio Code to take advantage of it. You can do in the Settings tab.

Side node: to open the Settings tab, you can use COMMAND + , on macOS or CTRL + , on Windows and Linux:

Visual Studio Code / Main view

At the top of the Settings tab you will find a search box. Now, you need to type formatter, and then Editor: Default Formatter will pop up on the settings list:

Visual Studio Code / Settings

Now, open the dropdown and select Prettier - Code formatter from the list:

Visual Studio Code / Settings / Default Formatter

Now, Prettier is your default code formatter, but you might want to enable Visual Studio Code to automatically format code when you save files.

If you want to, just tick the checkbox in the Format On Save section:

Visual Studio Code / Settings / Format On Save

How To Format Code with Prettier in Visual Studio Code

Let's take a look at one React component I created:

Visual Studio Code / Unformatted React 18 Component

As you can see, this code is completely misaligned, it misses semicolons, and it is very difficult to read. The code could formatted in a better way, right? Here's where Prettier comes into play.

To format code, we need to open the command palette – you can use COMMAND + SHIFT + P on macOS or CTRL + SHIFT + P on Windows and Linux.

Now, you need to find Format Document. Feel free to use the search box:

Visual Studio Code / Format Document command

After running Format Document your code becomes neat and clean:

Visual Studio Code / Formatted React 18 Component (with Prettier)

Conclusion

Integrating Prettier into Visual Studio Code is a game-changer for developers striving to maintain a consistent and high-quality codebase.

By automating the formatting process, you are not only adhering to coding standards but are also reducing the struggle that comes with manual code formatting. That's why every developer should use Prettier to ensure consistency in their codebase.

I hope this article helped you a lot. It'd mean the world to me if you shared it on your social media.

If you have any questions you can reach me on Twitter.

Learn React

Looking for a practical course to learn React?

🚀 Join my React 18 Course on Udemy.

This course includes:

• 🎥 5.5 hours on-demand video
• 📱 Access on mobile and TV
• 🗓️ Full lifetime access
• 🎓 Certificate of completion

Click below to enroll.

Click to get started

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.

But not everyone on the team will remember to run those commands every time they commit. How can we use Husky to add Git hooks to run them for us?

• What are Git Hooks?
• What is Husky?
• What are we going to build?
• Step 0: Setting up a new project
• Step 1: Installing Husky to a project
• Step 2: Configuring Husky to run Git hooks
• Step 3: Using Husky to format code with Prettier

What are Git Hooks?

Git hooks are scripts that you can set up to run at certain events in the Git lifecycle. These events include different stages of a commit, like before a commit (pre-commit) and after a commit (post-commit).

These are useful in that they allow developers to run custom code tasks or even enforce standards by automating other scripts to run those tasks.

What is Husky?

Husky is a tool that allows us to easily wrangle Git hooks and run the scripts we want at those stages.

It works by including an object right within our package.json file that configures Husky to run the scripts we specify. After that, Husky handles managing at which point in the Git lifecycle our scripts will run.

What are we going to build?

We’re going to set up a simple project that we can use to test out Git hooks.

While you should be able to follow along with any project that you’re working with, I’m going to use Next.js as the starting point for this project, simply for the fact that we can run a single command to get a project started.

One consideration about following along with this project, though, is that we’ll use Prettier as an example of what you can do with Git hooks.

Prettier is a tool that will automatically format our code for us, which if you’re not expecting that to happen, can cause a lot of stress. Following along with me using the Next.js project will allow you to test this out without making any unintentional changes.

As for testing the Git hooks, we’ll start by adding a simple command line statement to see Husky work. But we’ll also test out adding Prettier, which will automatically format our code for us.

Finally, at the time of writing this, Husky released an v5 Alpha version of their Git hook solution. Given it’s still just an Alpha version, we’re going to move forward with v4, which allows us to easily install Husky with npm.

Step 0: How to set up a new project

As I mentioned, you can really follow the same steps here with any project that’s managed with a package.json file.

Next.js is absolutely overkill for this walkthrough, but the goal is to minimize the steps for getting set up to actually work with Husky.

To get started with Next.js, navigate to the directory you want to start your project in and run the following:

yarn create next-app my-husky-project
# or
npx create-next-app my-husky-project

Note: feel free to replace my-husky-project to whatever you’d like to name your directory.

This will create a new folder, create a new Next.js project, and install all the dependencies.

Once it’s done, navigate to that new folder, and we should be ready to go!

Follow along with the commit.

Step 1: How to install Husky to a project

To install Husky, we can use yarn or npm.

yarn add husky
# or
npm install husky

Note: if installing Husky at this point installs v5, that means v5 has been officially released. Please see the updated Husky documentation or you can install the latest v4 version by specifying husky@4.3.0 (or whatever the latest version is) when installing.

Once the package is finished installing, we should be ready to go with Husky.

Follow along with the commit.

Step 2: How to configure Husky to run Git hooks

Next, we’re going to set up Husky so we can use it for our Git hooks.

Inside of our package.json file, create a new property called husky with an empty object.

"husky": {},

You can add this really wherever you want in the package.json file, but I’m going to add it right below the scripts property so I can more easily manage them together.

Inside of that, we want to add another property called hooks that also specifies an empty object:

"husky": {
  "hooks": {}
},

This is where we’re going to add our Git hooks. Husky supports pretty much all Git hooks defined by Git, so we can be as flexible we would like within our Git event flow.

To test this out, I created a new branch where I literally added every Git hook from that page including a script that simply writes to the terminal [Husky] event name.

Note: don’t feel like you need to do this unless you’re curious. The goal is to be able to show you with my example how it works.

“husky”: {
  “hooks”: {
    “applypatch-msg”: “echo \”[Husky] applypatch-msg\””,
    “pre-applypatch”: “echo \”[Husky] pre-applypatch\””,
    “post-applypatch”: “echo \”[Husky] post-applypatch\””,
    “pre-commit”: “echo \”[Husky] pre-commit\””,

What this will do is tell Husky that at every single stage where we’re permitted to hook into Git, tell us!

When I commit that change, we can immediately see that Husky fires off some of our scripts.

These are all of the events that Git allows us to hook into that happen during the commit process.

And similarly, if I push those changes out to Github, I can see that the push process runs the pre-push hook!

You may never use most of the hooks that Husky and Git provide (we only saw a few between those two commands).

But it’s awesome to be able to see how powerful this can be, whether it’s running code that formats our code, prevents secret access keys from being committed, or really anything else that can help automate important tasks to your workflow.

We can now see that we can configure Husky by specifying the configuration and the hooks right in our package.json.

Follow along with the commit.

Note: If you want to check out my branch that includes every Git hook to test with, you can find it on Github.

Step 3: How to use Husky to format code with Prettier

Finally, for a real-world use case, we’re going to test out using Prettier to automatically format our code.

Prettier is an opinionated code formatting tool that allows you to easily clean up your code to make it look like a single person wrote it.

Why are tools like Prettier important? When working through code, especially with a team, it’s important to maintain consistency so everyone knows what to expect. It will help prevent arguing over a semi-colon in a code review, but it will also help catch syntax errors and prevent bugs.

Warning: running Prettier will automatically format all of your code. While we’re going to test this out before committing the changes, once you apply this as a Git Hook, it will automate this process.

To get started with Prettier, let’s install it with our package manager:

yarn add prettier -D
# or
npm install prettier --save-dev

Note: we’re installing Prettier as a devDependency as our application doesn’t need this to run.

Next, we can add a new script in our package.json that will make it easier to run Prettier to test this out.

Inside the scripts property, add:

"lint": "prettier --check ."

For this first test, we’re going to run it as a “check” which will allow us to see which files would change.

Run the following:

yarn lint
# or 
npm run lint

And once we do, we can see that Prettier is telling us that would change the files listed.

At this point, our code will remain unchanged. But if we want to run Prettier for real to make those changes, we can first add an additional script:

"format": "prettier --write ."

And if we run that script, it will update all of those files to format the code to Prettier’s specification.

Warning: just another note, running Prettier to write the changes will make changes in your files. These are all code-style changes that shouldn’t impact how the code runs, but how the code looks. Before running format, you should save any changes by committing with Git so that you can easily revert the changes if you’re not happy with them.

You can now run the script with:

yarn format

And we can see that Prettier updated our files!

Now the part that’s relevant to this walkthrough: we can add this as a Git hook. This way, when someone tries to commit code, Prettier is run before the code is saved. This means that we’ll always keep code consistent with Prettier’s formatting style.

Inside our Husky hooks configuration, let’s add:

"husky": {
  "hooks": {
    "pre-commit": "prettier --write . && git add -A ."
  }
},

If you notice in our pre-commit hook, we’re also adding git add -A ..

When Husky runs, it simply runs the script provided. When running our Prettier command, we’re only formatting the code, but we never save those changes as part of the process. So we use git add to store all of those changes and include them in the commit.

To test this out, I reverted the changes to all of the files that were formatted before. If you’re following along with the same project, you can run:

git checkout pages

Which will reset all of the changes in pages to the last commit.

Now, let’s try to add all of our files with Git and commit the changes.

And once we run our commit command, we can see that the Husky pre-commit hook kicks in already and formats our code!

Follow along with the commit.

What can I do next?

Use lint-staged to only run formatting on changed files

We’re using Prettier right in our pre-commit hook and specifying . which means it’s going to run on all files every time.

We can use a tool called lint-staged, which allows us to still run our Git hooks with Husky, but it will only run on files that are staged.

For instance, if we wanted to do this with Husky and Prettier, our configuration might look like:

"husky": {
  "hooks": {
    "pre-commit": "lint-staged"
  }
},
"lint-staged": {
  "*": "prettier --write"
},

As part of how lint-staged runs, it will attach the changed files to the end of our Prettier statement automatically for us.

You’ll also notice we didn't include git add. lint-staged will also add any changes to Git for us automatically.

Set up a Prettier config to customize formatting rules

Prettier is very opinionated. There are some things I personally don’t prefer and you might feel the same.

Luckily, Prettier allows you to set up a configuration file that can override some of those files to make your code just the way you and your team want it.

Tell Prettier to ignore files with .prettierignore

You also probably don’t want Prettier running on “all the things” (maybe you do).

Prettier allows you to set up a .prettierignore file right inside of the root of the project next to package.json, similar to .gitignore, that allows you to tell Prettier what files it should not run on.

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/

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