GitHub and Twitter:

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.

SonarQube

sonarcloud.io/organizations/folio-org

See FOLIO-858 to encourage ‘A’ ratings.

Local use

The SonarLint extension for IDEs will detect quality issues at an early stage.

Use “Connected mode” to hook directly into our project rules.

Rule customization

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.

Other lint tools: raml-cop, jq

These are not included in continuous integration, but are certainly useful as local tools.

For RAML-using server-side projects use raml-cop to validate RAML/Schema and examples.

For JSON files, jq is useful for validation, pretty-printing and linting, and for many JSON processing and viewing tasks.