All code repositories have linter and code-style analysis facilities implemented as part of their continuous integration. The pull requests will run the relevant static code analysis tools.
This document explains those facilities and shows how to run tools locally before pushing changes.
The client-side projects use “ESLint”. The server-side projects use “SonarQube”. Actually, the SonarQube analysis reports are available for all projects, and provide additional useful analysis.
Preparing pull requests
The pull request will show the analysis messages of any new issues that arise from these code changes.
At this stage the contraventions will not prevent the merge to master.
Developers can minimise these reports by running the tools locally, and in some cases configuring the code lines to avoid certain tests.
See FOLIO-858 to encourage ‘A’ ratings.
See FOLIO-1049 to encourage ‘A’ ratings, 80% test coverage, and less than 3% duplicated lines.
The SonarLint extension for IDEs will detect quality issues at an early stage.
Use “Connected mode” to hook directly into our project rules.
See an example of using SuppressWarnings.
Regarding “Quality Profile” see issue FOLIO-864
ESLint for client-side projects
The Code quality section of The Stripes Module Developer’s Guide explains ESLint usage, how to run it prior to commit, and how to disable some lines.
RAML and Schema
For RAML-using server-side projects, raml-cop assesses RAML and schema and examples.
Other lint tools
These are not included in continuous integration, but are certainly useful as local tools.
For JSON files, jq is useful for validation, pretty-printing and linting, and for many JSON processing and viewing tasks.