How to properly set up Nuxt with ESLint and Prettier in VSCode
Writing tech tutorials is hard because certain configurations might stop working after several months. As I’m also working on other things I don’t always have time to check if this is still working. However, if this tutorial doesn’t work for you anymore, please let me know ASAP! I really don’t want to waste your time doing something that doesn’t work anymore.
With JavaScript being a dynamic and loosely-typed programming language problems and errors can potentially stay undetected for a very long time. To analyze code and to find errors, JavaScript applications are typically executed. This however, is a complete waste of processing power and hinders a fast development process.
As an alternative, static analysis tools can be used. One very common tool is “ESLint”, more specifically, it is a linting tool. Linting is defined as a type of static analysis that can be utilized to detect problematic code patterns or to enforce code style guidelines. This allows programmers to detect potential problems without executing the code. What is more, ESLint is a highly flexible and configurable in which every aspect can be adapted to fit a project’s needs. Configuring ESLint is not that hard, integrating custom rules, code formatting and properly setting up error highlighting is. This article aims to help developers who are using Nuxt and Visual Studio Code to set-up linting and code formatting.
Setting up linting and formatting requires 3 steps:
- Installing the needed development dependencies
- Installing VSCode extensions (needed for error highlighting etc.)
- Actually configuring ESLint to make it support
.vuefiles and to integrate code formatting
1. Installing dev dependencies
To install the development dependencies we issue the following command inside the root directory of our project:
npm install eslint babel-eslint eslint-config-prettier eslint-plugin-prettier eslint-plugin-vue eslint-loader prettier -DThis adds eslint (linting, error messages, etc.), babel-eslint (so we can use ES6+ features, flow types, etc.), eslint-config-prettier (special config for prettier so it will not interfere with other eslint formatting rules), eslint-plugin-prettier (runs prettier as an eslint rule so wrong formatting is seen as an error), prettier itself (to properly format code) and eslint-plugin-vue (adds vue support to eslint, e.g v-model cannot be used on a div element).
2. Installing VSCode extensions
The next step is to install some extensions, to enable error highlighting and automatic fixes. This step is fairly straightforward, we just need to install two extensions for VSCode:
Vetur: https://marketplace.visualstudio.com/items?itemName=octref.vetur
ESLint: https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint
By installing Vetur VSCode can now highlight the syntax of .vue files and by additionally installing the ESLint extension it is able to highlight syntax and pattern errors and errors which are defined by custom rules.
UPDATE: VSCode changed the settings and it is now easier than ever to get prettier + eslint to work. The snippet below has been updated to reflect these changes.
An important note here: please do yourself a favor by adding the following snippet to your workspace settings, not your global VSCode settings. This will create an additional file in your project structure, which can be tracked with git and therefore shared between developers.
3. Configuring ESLint and Prettier
The most important step is to actually configure eslint. I personally like to create a file called .eslintrc.js in my root folder which contains my settings as shown below. Another way would be to add the configuration to the package.json file which is a little less clean in my opinion.
In the extends array ESLint is instructed to use the plugins we installed as dependencies earlier. As these four lines are probably the most important part of this article I will further elaborate:
plugin:vue/recommendedtells ESLint to incorporate Vue specific rules (e.g you cannot use v-model on divs)eslint:recommendedconfigures ESLint to use some default best-practice rules like getters always need to return a value (full list here: https://eslint.org/docs/rules/)plugin:prettier/recommendedturns on botheslint-plugin-prettierandeslint-config-prettierwhich tells ESLint to treat prettier errors as linting errors and disable certain rules that interfere with prettier (should prevent weird loops).prettier/vueadds Vue specific formatting rules to prettier (e.g v-for comes before class)
The vue/component-name-in-template-casing rule defines that custom components should be written in PascalCase. Setting up the “no-console” rule like I did allows us to use console.log during development but treats it as an error when the project is in production mode, which is regarded as a best practice. Last but not least, we define $nuxt as a global variable, if we did not do this, it would throw the “no-undefined variables” error when accessing $nuxt. This is useful for example when we need to retrieve a route name with $nuxt.$route.name and don’t want to use “this”).
4. Roundup
By now your files should be nice and tidy when hitting save and errors should be highlighted as soon as your fingers hit the keys. The system we put in place should now look somewhat like this:
We’ve got the plugins for ESLint to integrate Prettier and Vue rules. Babel-eslint serves as the parser which allows us to write ES6+ code and still get linting capabilities. And we have the ESLint VSCode extension which tells the Vetur Extension which errors to highlight and then actually highlights them.
That’s it! It took me a lot of time to properly understand how to integrate ESLint together with Prettier as the documentation of Nuxt and Vue don’t quite touch these topics in depth. Also some other ESLint tutorials which were specifically written for Nuxt or Vue seem half-baked and I feel like some of the authors didn’t even bother to properly read the documentation of each tool leading to unnecessary dependencies and weird formatting.
I hope this both helps and saves you a ton of time. Btw, did you know you can clap up to 50 times on a single article? If not you should probably try it out :)
Happy Coding!
PS: Also see my other article about how to set up Jest and Nuxt from scratch: https://medium.com/@gogl.alex/nuxt-jest-setup-from-scratch-8905d3880daa