@max-iv/eslint-config-maxiv NPM

eslint-config-maxiv

Description

Linting rules for Max IV frontend code.

Installation & Config

Install the npm package npm install --save-dev @max-iv/eslint-config-maxiv

Extend the config in your local .eslint.config.js or equivalent:

// eslint.config.js
import maxiv from "@max-iv/eslint-config-maxiv";

export default [
  ...maxiv,
  // Overrides can go here
  {
    rules: {...}
  }
];

Extend your local prettier.config.js with the config included in this package:

// prettier.config.js
import { prettierConfig } from '@max-iv/eslint-config-maxiv';
export default prettierConfig;

It is a good idea to have the scripts ready in your package.json file:

  "scripts": {
    "format": "prettier --write .",
    "format:check": "prettier --check .",
    "lint": "eslint ."
  },

When everything is set up to your liking, run the formatter and then the linter by executing the following commands (it will format and lint the code, and automatically fix some of the issues found by the linter):
```
  npm run format
  npm run lint -- --fix
```

Recommended Setup

In order for this config package to make any effects in your codebase it needs to be setup in your environment.

It is recommended that you set up the linter/formatter to run whenever there is a change in the codebase. The best way of doing this is to set up it up in your CI-pipelines. Run the npm run format:check command added above to validate that the code is formatted correctly in your pipeline.

It is also strongly recommended to have the formatter and linter running in your IDE. If set up correctly the code you write will be formatted automatically when saving and any linting issues will be visible directly.

Visual Studio Code

Install the Prettier and eslint plugins and configure your IDE to use them on save.

Open the settings and search for 'Formatter', select Prettier in the dropdown

Open the json settings file and add the following lines to configure eslint to check for non-conforming code on the fly:

{
  "eslint.format.enable": true,
  "eslint.workingDirectories": [{ "mode": "auto" }],
  "eslint.validate": [
    "css",
    "html",
    "javascript",
    "javascriptreact",
    "typescriptreact",
  ],
}

If you do not get errors marked with red wavy underlines in your code:

Make sure your eslint executable is configured correctly. Best way to avoid this is perhaps to do npm install eslint -g to install it globally.
Check the output log and look for errors from eslint.

Rule Motivations

Here you can find motivations behind some of the rules in this config package.

Single Quotes

Prettier: singleQuote: true / eslint: '@stylistic/quotes': ['error', 'single']

Single quotes has a few advantages in javascript. Here are some of the main motivations to use this rule:

Consistency to other JS style guides. Google, Airbnb, Standard JS all use single quotes
Easier to type, no need for the shift key
Increased readability and reducing need for escaping, especially in HTML-
Helps to differentiate js from JSON, since JSON requires double quotes it is a good way of identifying what file is what at a glance

Line Width 1oo / 80

Prettier: printWidth: 100 / eslint '@stylistic/max-len': ... { code: 120, comments: 80 }

Keeping code and comments in shorter lines increases readability. The motivation behind allowing longer rows for the code is that it does not discourage devs from using descriptive naming of methods and variables.

Publishing New Versions

In order for the eslint config to be shared it is published to NPM. For this to work smoothly there is a script in the ./.gitlab-ci.yml file that triggers a publish job every time a tag is added. This setup does not allow for the version to be updated in the package.json file. It is set to 0.0.0 to mark that it is not updated.

When a change is merged back to the main branch, please update the npm version by tagging the commit with the desired version, and push the tag to git. The Gitlab tag interface can be used to add your tags directly. From there it is easy to see the latest version tag and create a new one on the main branch.

Alternatively you can follow these steps to do it from the terminal or your favourite git client:

Find the current version number, either by looking at the latest git tag, or by asking npm for the current version, npm show @max-iv/eslint-config-maxiv
Make sure to check out the main branch and pull the latest changes
```
git checkout main
git pull
```
Add a git tag with git tag -a x.y.z. Remember to increment the correct number compared to the currently published npm version. For smaller changes patch version should be incremented.
Push the tag to git, make sure the pipeline do not fail, git push --tags