Setting up a Formatter and Linter

Setting up a Formatter and Linter

Formatting and Linting#

As developers, we want to craft consistent and readable code. It is worth spending a little bit of extra time now to set up formatting and linting tools that will help keep your code clean and enforce good development practices.

Linting is the process of statically analyzing code for problems such as undeclared variables, unused variables and other syntax and best practice issues.

In this lesson, we will configure Prettier and ESLint and look at a few examples of how these tools help developers create more professional and bug-free code.


First off, go to the Extensions tab in VSCode and install the Prettier extension. This will integrate Prettier into VSCode.


Next, go to VSCode Preferences > Settings and search for format. Make sure the option Format on Save is checked.

format on save

Additionally, you may need to choose esbenp.prettier-vscode in the Default Formatter field under Settings:

default formatter

After this, head over to the command line under the frontend directory and install the following NPM dev dependencies:

The last step for setting up Prettier is to create the file frontend/.prettierrc.json containing the Prettier settings below. You can change these according to your own preference - for example, if you like semicolons with JavaScript, change the semi property to true.

Now, let's see it in action. Open App.svelte and hit Cmd-S or Ctrl-S to save the file. Since we have set Format on Save, VSCode should use Prettier's configuration to format the file.

You should notice that Prettier's settings have been implemented - for example, the semicolons may have been removed and the tab width changed from four to two.


Let's go one step further and install and configure ESLint. ESLint will apply a set of recommended rules to keep your code clean and, in some cases, prevent bugs. We'll try a couple of examples once we have completed the set-up.

Again, on the VSCode Extensions tab, install the ESLint extension. Then head back to the command line and under the frontend directory install a few more dev dependencies:

You guessed it! Next we need to create the file frontend/.eslintrc.json with the following config:

We are going to add ESLint to the npm build command in package.json. (We have not discussed it yet, but npm run build is the command to create a production build of our Svelte app.) We will add the ESLint command to the process so that the build process will fail if there are any linting errors.

Open up package.json and add npx eslint ./src && to the front of both the build and dev scripts:

Change this:

To this:

This will cause ESLint to run and lint the code every time we run a production build or start the local dev environment.

Testing ESLint#

In this section, we are going to purposefully write some bad code and let ESLint warn us about the issues.

First off, run a build from the command line in the frontend directory:

If there are no errors, then the command should output the following, and explain that the build process created a production bundle under the public directory.

Great. Now open up the App.svelte file in VSCode and add the line console.log(xyz). Can you spot the error? If not, ESLint will tell us in the next step.

Go back to the command line again, and run another build:

Perfect - this shows us ESLint in action. It catches a bug, prevents our production build and tells us that the variable xyz is not defined. If you look closely, you'll notice that it gives the file and the line number where the error was found, making it easy to fix the problem.

We've made great progress. In the next module, we will set up a Svelte router and stub out some pages in our application.

Start a new discussion. All notification go to the author.