Skip FOLIO Project Navigation

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.

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.

RAML and Schema

For RAML-using server-side projects, lint-raml assesses RAML and schema and examples. Those CI jobs utilise underlying tools such as raml-cop and raml-1-parser and z-schema.

Other lint tools

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

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

JSON Schema validator such as z-schema. See example use for local maintenance of ModuleDescriptors.