By default, Nestjs includes two very important tools that help us take care of the overall quality of the code we develop, ESLint and Prettier. They are configured by default to work together.
These tools target 2 specific types of rules, format or style rules, and code-quality rules. Let's start by clarifying the difference between a linter and a formatting tool.
- Format and Style rules: 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. Prettier is the tool that helps us with these types of rules. Some examples of these rules would be: max-len, no-mixed-spaces-and-tabs, keyword-spacing
- Code-quality rules: Refers to the attributes and characteristics of your code, identifying bad practices, potential security issues, potential performance issues, excessive complexity, and many other risk factors. ESLint is the tool that helps us with these types of rules. Some examples of these rules would be: no-unused-vars, no-extra-bind, no-implicit-globals
Next, we will see how to configure NestJs to get the most out of this pair of tools and strengthen the quality and security of the code you develop.
'use strict' feature was added to JavaScript in ES5. It has the literal meaning which is "the code should be in strict mode".
This restricts you from doing unintentional or silly mistakes like using an undeclared variable, not using type annotations, or trying to use a future reserved keyword as a variable name, etc. 'use strict' helps you write good and secure code by showing bad coding habits as syntax errors.
When Strict check is enabled, the following validations are automatically enabled:
alwaysStrict
noImplicitAny
noImplicitThis
strictBindCallApply
strictFunctionTypes
strictNullChecks
strictPropertyInitialization
useUnknownInCatchVariables
Warning: Take a good look at the configuration file and remove any settings that mentioned any of these validations.
For more information on compiler options, see the official TypeScript documentation.
The tsconfig.json file contains the build options that apply to the solution; some specific configurations must be added to ensure that some specific validations are performed at build time.
Although compilation options cover many aspects, at this point we will focus only on those that help us ensure the quality of our code.
"strict": true
"allowUnreachableCode": false
"allowUnusedLabels": false,
"noFallthroughCasesInSwitch": true
"noImplicitReturns": true
"noUnusedLocals": true
"noUnusedParameters": true
For more information on compiler options, see the official TypeScript documentation.
Since ESLint is already integrated into NestJs by default, we do not need to install any additional packages. When we create a project using the NestJs CLI , the default ESLint configuration corresponds to a basic set of validation rules.
The big advantage we have is that rule sets are defined, so there is no need to add them one by one, we just have to specify which rule set we need in our project.
In our case, we will choose strict rules to guarantee a good quality of our code. These rules are enabled by the following plugins:
plugin:@typescript-eslint/strict-type-checked
plugin:@typescript-eslint/stylistic-type-checked
This configuration is done in the .eslintrc.js file, as we see it below:
...
...
plugins: ['@typescript-eslint/eslint-plugin'],
extends: [
'plugin:@typescript-eslint/strict-type-checked',
'plugin:@typescript-eslint/stylistic-type-checked',
'plugin:prettier/recommended',
],
...
...
If you want to know more about the rules included in each set, you can read the plugin information in the official repository.
In addition to this configuration, we need to have the ESLint plugin installed, so we can integrate the linter into our IDE and see the errors as we code.
As for Prettier , it will take the style configuration defined in the ESLint package, so unless there is a conflict or we create a custom rule, we do not need to add any additional rules.
Additionally, we need to have the Prettier plugin installed, so we can integrate the code formatter into our IDE and see the errors as we code.
Another interesting option, especially if we have Sonar on our devops platform, is Sonarlint, this plugin is available for most popular IDEs, and like ESLint it allows us to evaluate in real time the quality of the code we are writing, with the plus we can connect to Sonar and perform an advanced scan of our code, all before uploading it to the repository, providing an additional level of quality.
I use the Sonarlint plugin for VSCode, you can find the information on how to configure it in the plugin page.
Fabian A. Becerra M. https://github.com/fabecerram
Code and documentation copyright 2019-2023 the authors. Code released under the MIT License.