Formatting and linting
General guidelines
Setting up
The project contains the following linters, plugins and extensions:
| Linter | Plugins / extends | Additional info |
|---|---|---|
| ESlint | eslint:recommended | |
| ESlint | airbnb | The airbnb plugin for ESlint was tested against this use case. |
| ESlint | react | |
| ESlint | prettier | We are not using prettier directly, but using prettier through eslint, to give ourselves better control over the ruling and formatting and count less on external plugins. If you have a prettier plugin on your IDE you should disable it for this project. The Prettier-Eslint plugin is used in this project with the recommended rule set. it was tested against this use case. |
| ESlint | typescript-eslint | We are not using the infamous TSlint, but a plugin that migrates the linting rules to typescript files, info on why here |
| Stylelint | stylelint-config-standard | |
| Stylelint | stylelint-a11y | These accessibility rules are in action to make sure the website is accessible through assistive technologies like screen readers and other devices for the visually impaired. |
| Stylelint | stylelint-scss | |
| Stylelint | stylelint-selector-bem-pattern |
The project contains a settings.json under the .vscode folder, which enables auto fixing and formatting on save. This would only work when working with VScode of course, and when the following extensions are installed:
Avoiding rules
Generally, the assumption should be that linting rules are there for a reason. If you encounter a warning or error which you don't understand, you can read about it in the following documentations:
If the rule name has a prefix (e.g. a11y/no-display-none or react/jsx-filename-extension) it is applied from a plugin, and therefore the information about it might be found in a seperated documentation.
Rules can generally be ignored with the following syntaxes:
But this is generally a bad practice. If you think the rule should be taken down completely, have exceptions or be changed in severity (from warning to error or vice versa), consider changing it in the .eslintrc.json / .stylelintrc.json files, and include a solid reasoning in your commit message.
Required changes for future linting
- stylelint's autofix common solution was down when this project have been set up, and therefore our current should be switched when stylelint’s team provides their own - further info here.