Analyse statique JavaScript avec ESLint et Biome

Si vous pratiquez JavaScript depuis quelque temps, vous avez probablement entendu parler d’ESLint, l’outil de référence pour l’analyse statique du code JavaScript. Mais connaissez-vous Biome ? Ce concurrent montant de Prettier pour le formatage du code fait parler de lui dans l’écosystème JavaScript. Biome va au-delà du formatage du code et propose un outil d’analyse de la qualité du code, ce qui en fait une alternative à ESLint.

Commençons par une brève introduction au formatage et à la qualité du code, deux outils et enjeux importants pour les développeurs JavaScript. Comme vous l’imaginez, préserver la qualité du code et respecter les conventions de formatage contribue à la réussite de tout projet logiciel, en particulier lorsque vous travaillez en équipe.

La qualité du code concerne son comportement à l’exécution. Un code de qualité est efficace, facile à comprendre et sans bogues. Le formatage du code, qui fait partie du style de code, porte quant à lui sur son organisation visuelle afin de le rendre lisible et compréhensible.

// Convention of preferred code formatting and quality
function add(a, b){
  return a + b;
}

// An example for what would be considered as
// poor code formatting, making it hard to read
// and error-prone
function add(c,d){return c+d;}

Dans l’écosystème JavaScript, plusieurs outils aident les développeurs à préserver le formatage et la qualité du code. Parmi eux, ESLint et Biome sont devenus des choix populaires pour rationaliser leur base de code.

Présentation de Biome et ESLint

ESLint est un outil open source d’analyse du code JavaScript qui aide les développeurs à produire du code JavaScript de qualité. Il leur permet de repérer les modèles problématiques ou le code qui ne respecte pas certaines règles de style. Très personnalisable, il peut être configuré pour faire respecter différentes normes de programmation.

ESLint est très populaire et extensible : vous pouvez ajouter des règles personnalisées pour faire respecter vos normes de programmation. Par exemple, vous pouvez imposer l’utilisation de points-virgules à la fin de chaque instruction ou de guillemets simples plutôt que doubles pour les chaînes.

Si vous avez parcouru un projet JavaScript, vous avez peut-être vu un fichier .eslintrc.js semblable à celui-ci :

// .eslintrc.js
module.exports = {
    "rules": {
        "semi": ["error", "always"],
        "quotes": ["error", "double"]
    }
};

Biome, en revanche, est un outil relativement récent de l’écosystème JavaScript, axé sur le formatage du code et l’analyse de sa qualité. Vous avez peut-être déjà entendu parler de Prettier ou l’avez utilisé. C’est là que Biome entre en jeu. Écrit en Rust, il est conçu pour être plus rapide. Biome est largement prescriptif, mais propose quelques options configurables. Voici un exemple de fichier biome.json :

{
  "javascript": {
    "formatter": {
      "indentWidth": 2,
      "lineWidth": 100,
      "trailingComma": "none",
      "semicolons": "always",
    }
  }
}

Actuellement, Biome est compatible avec les fichiers JavaScript, TypeScript, JSX et JSON.

Le passage de Prettier à Biome et l’accent mis par ESLint sur la qualité du code

Traditionnellement, de nombreux développeurs JavaScript s’appuient sur Prettier pour formater leur code. Toutefois, l’arrivée de Biome entraîne un changement. Biome vise avant tout la vitesse et les performances. Écrit en Rust, il est jusqu’à 35 fois plus rapide que Pettier pour formater plus de 170 000 lignes de code réparties dans 2 000 fichiers. La vitesse peut faire une grande différence dans le processus de développement lorsque vous travaillez sur une base de code volumineuse.

Cela ne signifie pas qu’ESLint va disparaître. Au contraire, ESLint reste un outil puissant pour préserver la qualité du code. Biome s’intéresse à l’apparence du code, tandis qu’ESLint se concentre sur son comportement. Ces outils sont complémentaires : Biome se charge du formatage, tandis qu’ESLint vérifie que le code respecte les bonnes pratiques et ne contient pas d’erreurs courantes.

Biome et ESLint sont tous deux des outils utiles dans l’arsenal des développeurs JavaScript. Ils jouent chacun un rôle important dans le maintien de la qualité et du formatage du code, pour une base de code plus fiable et plus facile à maintenir.

Utiliser Biome dans un projet JavaScript

Biome s’appuie sur un outil en ligne de commande qui effectue une analyse statique du code. Sa grande flexibilité est un atout : les développeurs peuvent définir leurs propres règles ou utiliser un ensemble de règles par défaut. Cette souplesse permet de faire respecter les normes de programmation et les bonnes pratiques dans n’importe quel projet JavaScript.

Voici un exemple d’utilisation de Biome avec JavaScript :

# Install Biome as a development dependency
npm install --save-dev @biomejs/biome

Notez qu’après l’installation, Biome doit exécuter un script d’installation pour récupérer les fichiers binaires nécessaires à votre plateforme. Ensuite, poursuivez :

# Initialize a new Biome configuration file
npx @biomejs/biome init

Cette commande crée un fichier de configuration biome.json à la racine de votre projet. Vous pouvez ensuite le personnaliser pour définir les règles et les paramètres de votre projet. Par défaut, les paramètres sont les suivants :

{
	"$schema": "https://biomejs.dev/schemas/1.5.3/schema.json",
	"organizeImports": {
		"enabled": true
	},
	"linter": {
		"enabled": true,
		"rules": {
			"recommended": true
		}
	}
}

Comme vous pouvez le constater, la configuration par défaut ne comporte pas de règles de formatage, ce qui peut la rendre incompatible avec la configuration Prettier de votre projet. Dans mon cas, le fichier .prettierrc.js ressemble à ceci :

module.exports = {
  printWidth: 100,
  tabWidth: 2,
  singleQuote: true,
  semi: false,
  trailingComma: 'none',
  useTabs: false,
  bracketSpacing: false
}

Pour rendre Biome aussi compatible que possible avec les règles de formatage Prettier ci-dessus, vous pouvez ajouter ce qui suit au fichier biome.json :

{
  "formatter": {
    "enabled": true,
    "indentStyle": "space",
    "indentWidth": 2,
    "lineWidth": 100,
    "quoteStyle": "single",
    "trailingComma": "none",
    "semicolons": "asNeeded",
    "bracketSpacing": true,
    "arrowParentheses": "asNeeded"
  }
}

Nous pouvons maintenant exécuter le formateur de Biome sur notre base de code :

npx @biomejs/biome format ./src

Il ne reste alors qu’une seule règle de formatage propre à Biome, qui n’est pas configurable et concerne l’espacement des fonctions :

./src/Utils.js format ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  ℹ Formatter would have printed the following content:

     2  2 │
     3  3 │   module.exports = {
     4    │ - ··parseUrl:·function(urlToScan)·{
        4 │ + ··parseUrl:·function·(urlToScan)·{
     5  5 │       if (urlToScan === undefined) return urlToScan
     6  6 │
    ····· │
    12 12 │       return urlToScan
    13 13 │     },
    14    │ - ··trimUtmParams:·function(urlToTrim)·{
       14 │ + ··trimUtmParams:·function·(urlToTrim)·{

Vous pouvez aussi abandonner complètement la configuration Prettier et utiliser les règles de formatage de Biome.

Combiner formatage et analyse avec Biome

Biome propose également un outil d’analyse qui permet de faire respecter les règles de qualité du code et peut être considéré comme une alternative à ESLint. Vous pouvez le configurer pour appliquer un ensemble de règles par défaut ou des règles personnalisées définies dans le fichier de configuration biome.json.

Pour lancer l’analyse de Biome, nous utiliserons la commande biome check afin de détecter toute violation des règles définies dans l’ensemble de règles recommandé par défaut de biome.json.

# Run Biome on your code
npx @biomejs/biome check ./src

Dans mon dépôt de code, où j’ai essayé Biome, j’ai obtenu le résultat suivant :

./src/Audit.js:30:7 lint/complexity/useOptionalChain  FIXABLE  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  ✖ Change to an optional chain.

    29 │     if (
  > 30 │       vulnerableAudit.details &&
       │       ^^^^^^^^^^^^^^^^^^^^^^^^^^
  > 31 │       vulnerableAudit.details.items &&
       │       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    32 │       vulnerableAudit.details.items.length > 0
    33 │     ) {

  ℹ Unsafe fix: Change to an optional chain.

     28  28 │
     29  29 │       if (
     30     │ - ······vulnerableAudit.details·&&
     31     │ - ······vulnerableAudit.details.items·&&
         30 │ + ······vulnerableAudit.details?.items·&&
     32  31 │         vulnerableAudit.details.items.length > 0
     33  32 │       ) {

./src/RenderJson.js:27:7 lint/complexity/noForEach ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  ✖ Prefer for...of instead of forEach.

    25 │       vulnerabilitiesResults.details.items.length > 0
    26 │     ) {
  > 27 │       vulnerabilitiesResults.details.items.forEach(vulnItem => {
       │       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  > 28 │         vulnerabilitiesCount += vulnItem.vulnCount
  > 29 │         const vulnInfo = this.formatVulnerability(vulnItem)
  > 30 │         vulnerabilities.push(vulnInfo)
  > 31 │       })
       │       ^^
    32 │     }
    33 │

  ℹ forEach may lead to performance issues when working with large arrays. When combined with functions like filter or map, this causes multiple iterations over the same type.

The number of diagnostics exceeds the number allowed by Biome.
Diagnostics not shown: 15.
Checked 4 file(s) in 3ms
Found 35 error(s)
check ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  ✖ Some errors were emitted while running checks.

Il existe donc de nombreux écarts par rapport aux configurations ESLint et Prettier que j’utilise déjà. À vous de décider si vous préférez utiliser l’outil d’analyse et les règles de formatage prescriptives de Biome, ou reprendre autant que possible votre configuration existante à l’aide de son ensemble de règles et d’options.

Les commandes biome ci et biome explain

La commande biome ci est pratique dans un environnement d’intégration continue (CI). Elle vérifie le code à la recherche de violations des règles définies dans le fichier de configuration biome.json. Si elle en trouve, elle se termine avec un code de statut non nul, signalant un échec.

Voici un exemple d’utilisation de la commande biome ci :

# Check your code using biome ci
npx @biomejs/biome ci ./src

La commande biome explain, quant à elle, fournit des informations détaillées sur une règle précise. Elle explique pourquoi cette règle est importante et comment les violations peuvent nuire à la qualité de votre code. Elle affiche même un extrait de code pour illustrer la règle.

Par exemple, pour comprendre la règle « useArrowFunction », vous pouvez exécuter la commande suivante :

# Understand a specific rule
npx @biomejs/biome explain useArrowFunction

Un document Markdown s’affiche alors dans la console pour expliquer la règle en détail.

# useArrowFunction

Fix is Safe.

This rule is recommended.

# Description
Use arrow functions over function expressions.

An arrow function expression is a compact alternative to a regular function expression,
with an important distinction:

this is not bound to the arrow function. It inherits this from its parent scope.

This rule proposes turning all function expressions that are not generators (function) and don't use this into arrow functions.

## Examples

### Invalid

const z = function() {
return 0;
}

const delegatedFetch = async function(url) {
return await fetch(url);
}

const f = function() {
return this.prop;
}

Named function expressions are ignored:

const z = function z() {
return 0;
}

Function expressions that declare the type of `this` are  also ignored:

const z = function(this: A): number {
return 0;
}

Utiliser Biome dans VS Code

Les utilisateurs de Visual Studio Code (VS Code) peuvent profiter d’une extension Biome dédiée, qui intègre toute sa puissance et ses fonctionnalités directement dans l’IDE. Elle propose notamment l’analyse en temps réel, le formatage automatique et bien plus encore.

Pour utiliser Biome dans VS Code, procédez comme suit :

1. Installez l’extension Biome depuis la marketplace de VS Code.

2. Ouvrez la palette de commandes (View ou Ctrl/⌘+⇧+P), sélectionnez Format Document With, puis Configure Default Formatter et enfin Biome.

Biome et le projet Node.js

L’une des évolutions récentes importantes concernant la base de code du projet Node.js est la pull request ouverte par Yagiz Nizipli, qui vise à faire de Biome le formateur de code par défaut.

L’intégration de Biome dans la base de code du projet Node.js constitue une avancée majeure pour garantir la cohérence du formatage. Dans une base de code aussi volumineuse que celle de Node.js, les performances à l’exécution du formatage et de l’analyse de la qualité du code sont essentielles pour offrir aux contributeurs un retour rapide.

Conclusion

Cela signifie-t-il qu’ESLint et Prettier vont disparaître ? Pas du tout. ESLint reste un outil puissant pour préserver la qualité du code ; il est facile à étendre avec des règles personnalisées et est largement utilisé dans de nombreux projets de l’écosystème. Prettier reste lui aussi un choix populaire pour le formatage du code. Biome s’impose toutefois comme une alternative plus rapide à Prettier et comme un outil d’analyse de la qualité du code susceptible de remplacer ESLint.

Adoptez des pratiques de programmation sécurisée

Découvrez les ressources de Snyk Learn pour vous aider à écrire du code sécurisé et de qualité.

Si vous appréciez l’analyse statique du code pour le formatage et l’analyse, l’extension Snyk pour VS Code vous sera très utile : elle fournit un retour en temps réel sur les vulnérabilités de sécurité du code et les vulnérabilités open source. Pour approfondir vos connaissances et renforcer votre maîtrise des pratiques de programmation sécurisée, inscrivez-vous sur Snyk. Cette plateforme dédiée à la sécurité pensée pour les développeurs met à votre disposition de nombreuses ressources pour vous aider à écrire du code sécurisé et de qualité.