Skip to main content

Code Style

:::

info

This content is mandatory

This best practice details the styling and linting for Typescript projects.

Rationale​

ESLint​

ESLint allows code to be more consistent and avoids bugs early in the process. It helps keep our code clean and of a high quality.

The ESLint config is extended from defaults and is a collaborative effort between engineers.

Prettier​

Running Prettier on all files helps ensure that the formatting for all files remains the same. It reduces the noise in commits by removing any space changes and formatting differences that can occur between engineer setups. As a result the git diffs and history become clearer and do not contain formatting changes.

The default Prettier config was used as this is acceptable for our needs and can be easily implemented out of the box by engineers.

We decided that it is best to run prettier after ESLint such that prettier formatting overrides ESLint formatting. As of version 3.0.0 of the @cruk/eslint-config package, we use eslint-plugin-prettier which enables Prettier to be run as an ESLint rule.

Description​

At CRUK it was decided that all products we develop will align on ESLint and Prettier rules.

The @cruk/eslint-config package has been created and published to capture these rules such that they can be shared across the organisation.

Follow the installation instructions on the eslint-config repo for details on how to implement the ESLint and Prettier configurations.

Implementation​

There are several ways of running ESLint and Prettier in your workflow and which method you choose can be made on an individual/team basis.

As of version 3.0.0 of the @cruk/eslint-config package, you will only need to run ESLint to perform both linting and formatting, as Prettier is run as an ESLint rule using eslint-plugin-prettier.

Implementation examples​

The engineering-guidebook repository has the CRUK ESLint config implemented and used.

Overriding rules​

Whilst not recommended where possible, specific rules can be turned off either by line, code block or throughout a whole project. This should only be used where necessary, for example if encountering errors with third-party or legacy code which does not comply with our standards. Every effort should be made to refactor and update the relevant code so any overrides can be removed.

Overriding rules in eslintrc​

{
  "rules": {
    "@typescript-eslint/no-unsafe-return": "off" // Comment to explain why this is needed
  }
}

Overriding rules inline​

alert("foo"); // eslint-disable-line no-alert

// eslint-disable-next-line no-alert
alert("foo");

See the ESLint documentation for more examples.

References & Further Reading​