Lint (eslint stylelint prettier)

The repository expose "lint" for multiple use cases:

• CI
• Editor: the developer has if possible by default a configuration that activate lint so non respected rules are shown.
• pre-commit hook.

But always remenber lint can not be enforced due to false positive or acceptable issues sometime. For example you can have a conflict between rules and formatter. The error can be accepted in some context. The linter may have an issue. That may change in the future but for now this is not enforced.

CI

On every commit the CI will check you have not introduce code that do not respect lint rules. It creates annotation so the reviewer can see them.

VScode

VScode by default will execute eslint on every files. And by default eslint will do a reverse cascade to find an eslint configuration in parent folder of the file. Do not hesitate in case of doubt to check the output panel and choose eslint. For example you may have an typescript project but with a commonjs file for webpack configuration.

pre-commit

Using lint-staged lib we have setup eslint and prettier to be called. But we have more and more code and we have been hit by an issue At the moment we have removed the pre-commit hook of eslint.

To make it happens we need to filter files in it to match configuration of each packages. If you lint a file not supported by the configuration it will create an error so the commit will not be possible without the --no-verify option. To make it happens again we need ensure all packages follow the same rule (src folder ?) so we can exclude all the configuration files.

Conclusion

Best effort: We may not lint every files as it consume a lot of time and memory and it creates complexity (ts/ejs/cjs) but we do our best to keep our code base standard.