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 utilised 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 -D
This 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:
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.
Further, with the following options inside the settings of VSCode we instruct the ESLint extension to actually validate
.vue files and to show us errors. By setting
editor.formatOnSave to false we make sure that VSCode itself will not try to format the code we write, which is very important because this will be handled by eslint and prettier. If it was set to true VSCode could interfere with our solution leading to very weird results. The
eslint.autoFixOnSave option instructs the ESLint extension to try and autofix any errors upon saving. The
vetur.validation.template option turns off Vetur’s template validation which doesn’t support rule configuration (just to make sure we don’t use unneeded stuff which might interfere).
An important note here: please do yourself a favour 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. More importantly, it helps you to manage and override different settings: for example if you also code in python and like your code being auto-formatted when saving, you could say
editor.formatOnSave: true in your global settings, which would create problems in your Vue/Nuxt based project. By using a workspace-based settings file you could just set this to false and life would be good again.
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 cleaner in my opionion.
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 both
eslint-config-prettierwhich tell 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”).
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 :)
PS: Also see my other article about how to set up Jest and Nuxt from scratch: https://firstname.lastname@example.org/nuxt-jest-setup-from-scratch-8905d3880daa