Guide d'adoption d'ESLint : présentation, exemples et alternatives

Écrit par Sebastian Weber✏️

Depuis de nombreuses années, ESLint est le standard de facto pour le linting des projets JavaScript et TypeScript. Ce guide d'adoption explique pourquoi c'est toujours le cas pour 2024.

Cet article couvre la version actuelle d'ESLint, qui était disponible au moment de la rédaction de cet article à l'été 2024 (v9.7). Par conséquent, seuls les concepts et fonctionnalités de la v9 sont décrits, ce qui apporte des changements majeurs par rapport aux versions précédentes.

Si vous souhaitez utiliser des versions plus anciennes sans la version de configuration la plus récente avec des fichiers de configuration plats, vous pouvez consulter le guide de migration officiel.

Qu’est-ce qu’ESLint ?

ESLint est un linter JavaScript configurable et extensible pour effectuer une analyse de code statique. Il vous aide à tracer et à résoudre les problèmes de votre code source sans avoir besoin de l'exécuter. Les problèmes peuvent aller de bogues d’exécution potentiels à de mauvaises pratiques de codage en passant par des problèmes de formatage du code.

En tant qu'outil de qualité logicielle, ESLint vise à rendre le code plus cohérent et plus robuste. Il vérifie votre code à l'aide d'assertions, appelées règles de charpie, concernant l'apparence ou le comportement de votre code. Par exemple, avec la règle no-use-before-define, vous pouvez demander à ESLint de signaler les violations lorsqu'il rencontre des appels de fonction avant qu'ils ne soient déclarés.

De plus, la gravité des violations peut être spécifiée pour chaque règle comme étant un avertissement ou une erreur. Ainsi, dans un pipeline CI/CD, une étape de peluchage pourrait échouer en raison d’erreurs signalées indiquant un problème plus important qui doit être étudié.

ESLint, à l'aide d'analyseurs et de plugins, peut être configuré pour comprendre et lint les extensions de syntaxe TypeScript ou JavaScript, comme JSX, ou les concepts de frameworks JavaScript comme React ou Vue.

Pourquoi ESLint a-t-il été créé ?

L'idée d'ESLint est née en raison des insuffisances des outils de peluchage disponibles à l'époque, tels que JSCS, JSLint et JSHint. Ces outils étaient quelque peu rigides dans leurs ensembles de règles et leurs capacités de configuration, ce qui rendait difficile l'ajustement des règles en fonction des exigences spécifiques de leur projet.

Depuis la version initiale d'ESLint, les règles ont constitué l'épine dorsale d'ESLint. Ils peuvent proposer des suggestions sur la façon de résoudre manuellement les violations affichées directement aux positions de code problématiques à l'intérieur des éditeurs de code avec des marqueurs et des superpositions.

De plus, les règles peuvent fournir des correctifs qui permettent à ESLint de résoudre automatiquement les violations à partir de la CLI ou de votre éditeur de code ; par exemple, refactoriser votre fonction de flèche en une variante de retour implicite.

En plus d'une bien meilleure expérience de peluchage avec une prise en charge plus large des outils et des langages, un autre argument de vente d'ESLint était et est toujours l'architecture enfichable. Il permet une plus grande extensibilité et personnalisation que ses concurrents, permettant aux développeurs de créer et de partager des règles personnalisées et d'étendre ESLint au-delà de ses fonctionnalités de base.

La preuve de la montée en puissance d'ESLint au fil des années est sa fusion avec JSCS, qui perdait du terrain au fil du temps. Depuis sa création, ESLint a considérablement évolué :

• ES6 et au-delà — ESLint a continuellement mis à jour son ensemble de règles pour s'adapter aux nouvelles normes ECMAScript, offrant ainsi une prise en charge native des dernières fonctionnalités JavaScript et extensions de syntaxe, telles que JSX. Vous pouvez également étendre ESLint pour comprendre d'autres langages à l'aide de projets associés ; par exemple, typescript-eslint pour prendre en charge TypeScript
• Intégration et écosystème — L'outil a connu une meilleure intégration avec divers environnements de développement, des outils de construction (par exemple, le plugin ESLint pour le formatage Prettier) et des éditeurs de code (par exemple, l'extension ESLint VS Code). La communauté a contribué à une large gamme de plugins pour différentes bibliothèques et frameworks (par exemple, le plugin ESLint officiel pour Vue.js) pour prendre en charge les composants à fichier unique de Vue, rendant ESLint polyvalent dans différents écosystèmes JavaScript
• Améliorations des performances — ESLint a apporté des améliorations significatives des performances au fil du temps, ce qui accélère l'analyse des bases de code volumineuses.

Quand il s'agit de maintenir la qualité et la cohérence du code dans les projets JavaScript, ESLint se distingue comme un outil de premier ordre. L'adopter dans vos projets peut améliorer considérablement le DX, garantissant que vos bases de code restent propres, lisibles et exemptes d'erreurs.

ESLint est livré avec de nombreuses règles qui peuvent facilement être adaptées aux exigences d'un projet. Vous pouvez même ajouter plus de règles à l'aide de plugins communautaires. De plus, les analyseurs peuvent être utilisés pour étendre les fonctionnalités d'ESLint.

Lectures complémentaires :

• Utilisation de Prettier et ESLint pour le formatage JavaScript

Utiliser ESLint

Avant de pouvoir approfondir les concepts et fonctionnalités de base d'ESLint, nous devons d'abord configurer le flux de travail ESLint.

Ajouter ESLint à votre projet

Dans un dossier avec un package.json existant, vous pouvez exécuter la commande suivante pour ajouter ESLint à votre projet de développement. ESLint est destiné à être installé localement. Avec la commande suivante, vous pouvez exécuter un guide d'installation interactif qui ajoute la configuration ESLint par défaut :

# run at root level of your project
$ npm init @eslint/config@latest

Vous pouvez également lancer votre projet avec une configuration partageable. Vous pouvez en trouver beaucoup en effectuant une recherche sur Github. La convention de dénomination consiste à commencer les configurations personnalisées avec eslint-config-.

L'assistant d'installation vous pose quelques questions sur la configuration actuelle de votre projet : Une fois l'installation terminée, ESLint a créé un fichier de configuration avec un suffixe de fichier en fonction du type de variante de module que vous avez choisi. Pour ESM, vous trouvez un eslint.config.mjs dans votre répertoire de travail. Par convention, le préfixe du fichier .mjs indique que vos projets fonctionnent avec ESM mais eslint.config.js aurait le même effet.

Travailler avec la configuration plate d'ESLint

Cette configuration dite plate pour un projet JavaScript vanilla ressemble initialement à ceci :

// eslint.config.mjs
import globals from "globals";
import pluginJs from "@eslint/js";
export default [
  { languageOptions: { globals: globals.browser } },
  pluginJs.configs.recommended,
];

Avec cette configuration ci-dessus, le package npm JavaScript ESLint par défaut @eslint/js est utilisé avec un environnement de navigateur (globals.browser) et toutes les règles JS recommandées. Créons un simple fichier JavaScript avec quelques violations de règles :

// playground.js
var testVar = "This should be 'let' or 'const'";
undefinedFunctionCall();

Nous exploitons la CLI ESLint avec npx à partir du même chemin où se trouve eslint.config.mjs :

$ npx eslint # all files recursively
$ npx eslint playground.js # specific file(s)
$ npx eslint *.js # ESLint supports globs

Dans cet exemple, ESLint a signalé deux erreurs dues à une violation des règles no-unused-vars et no-undef : Le projet ESLint GitHub est organisé en monorepo, et vous pouvez consulter plus d'options de configuration en consultant le package @eslint/js. La configuration ci-dessus ajoute toutes les règles recommandées, qui ont toutes un niveau de gravité d'erreur. Nous en apprendrons davantage sur la gravité des violations dans une minute.

La configuration suivante montre différentes variantes d'utilisation des règles recommandées :

export default [
  // ...
  // pull in all recommended rules
  pluginJs.configs.recommended,
  // all but different approach
  { rules: pluginJs.configs.recommended.rules },
  // all but override existing rules
  {
    rules: {
      ...pluginJs.configs.recommended.rules,
      // change the severity level
      "no-unused-vars": "warn",
    },
  }
];

L'extrait suivant démontre qu'ESLint fournit des règles JavaScript prêtes à l'emploi puisque vous pouvez les utiliser sans rien importer en connaissant le nom. Cependant, cela n'est pas recommandé :

import globals from "globals";
export default [
  { languageOptions: { globals: globals.browser } },
  {
    rules: {
      "no-unused-vars": "warn",
    },
  },
];

Intégrer ESLint à votre éditeur de code

Il existe une grande variété de façons d'intégrer ESLint dans les chaînes d'outils, les éditeurs et les IDE. Si vous souhaitez que VS Code met en évidence les violations de règles dans vos fichiers sources, il vous suffit d'installer l'extension ESLint officielle : Si jamais vous vous trouvez dans une situation où l'extension ESLint dans VS Code ne répond pas à vos modifications de configuration , l'une des options suivantes vous aidera généralement.

Tout d'abord, jetez un œil au panneau de sortie de VS Code, sélectionnez ESLint dans la liste déroulante et recherchez une erreur : Deuxièmement, redémarrez le serveur ESLint interne à l'aide de la palette de commandes et exécutez ESLint : Redémarrez le serveur ESLint .

Ajout de la prise en charge de TypeScript

Avec le guide d'installation interactif, si vous sélectionnez TypeScript, la configuration utilise typescript-eslint pour apprendre à ESLint comment interpréter TypeScript. Vous pouvez également installer la prise en charge de TypeScript manuellement. Assurez-vous d'installer la bonne version (≥ v8.0.0-alpha.10) compatible avec ESLint v9 et la configuration plate :

$ npm i -D eslint @eslint/js @types/eslint__js typescript typescript-eslint@8.0.0-alpha.10 --force

Avec la configuration suivante, vous utilisez les règles JavaScript recommandées d'ESLint en combinaison avec les règles TypeScript recommandées fournies par typescript-eslint :

// eslint.config.mjs
import eslint from "@eslint/js";
import tseslint from "typescript-eslint";
export default tseslint.config(
  eslint.configs.recommended,
  ...tseslint.configs.recommended
);

La capture d'écran suivante montre que npx eslint ainsi que l'extension VS Code ESLint signalent toutes deux les violations JS et TS :

Concepts et fonctionnalités clés d'ESLint à connaître

La section précédente a donné un aperçu pratique de la façon dont ESLint est configuré et utilisé. Dans ce qui suit, j'aborderai les concepts de base que vous devez comprendre pour utiliser ESLint de manière rentable.

En savoir plus sur la configuration plate

Avec le nouveau concept de configuration plate, l'ensemble de la configuration du projet fait partie d'un seul fichier eslint.config.js(c|j|m). Auparavant, la configuration pouvait être répartie sur plusieurs fichiers .eslintrc et même faire partie de package.json, ce qui entraînait complexité et confusion.

Typically your flat config file is slim, as ESLint comes with reasonable default values for projects. By default, ESLint searches for source files with the suffixes .js, .mjs, and .cjs. In what follows, the terms flat config and eslint.config are used synonymously. The latter is representative of all file extensions (.*js).

When you use typescript-eslint, out-of-the-box ESLint will lint .ts, .tsx, .mts, and .cts files. As another example, all files with prefix .cjs are treated as JS files using CommonJS modules. Further, ecmaVersion: "latest" is the default, so ESLint expects you to work with the most recent version of ECMAScript:

{
  files: ["**/*.cjs"],
  languageOptions: {
      sourceType: 'commonjs',
      ecmaVersion: 'latest'
  },
},

How do you know about these default values? ESLint ships a handy visual tool to inspect your eslint.config. With the ESLint Config Inspector, you learn how the configuration concept works. Similar to the CSS DevTools in browsers, where you can see how the styles come about, you find out what default values are applied or how rules get applied for different file globs: This tool is valuable since the effective configuration object returned by eslint.config may not be apparent when simply looking at the file. This is especially true because you can import external configurations or generate parts of the configuration on the fly. You can run it with the following command:

$ npx @eslint/config-inspector

The concept of eslint.config is pretty straightforward, you have to return an array of config objects. Every config object adds either configuration for all files or a subset of files specified by a file glob. Consequently, multiple config objects can be composed to an overall configuration. If you skip the files property, the config object applies to all files: ESLint takes care to merge all the config objects into one effective configuration. This can be traced with the help of the ESLint Config Inspector.

For files matching *.jsx, the languageOption is configured to interpret JSX files. Otherwise, ESLint does not understand how to handle JSX files. The optional name property is useful in combination with the Config Inspector to improve traceability: The languageOptions property is where ESLint gets to know what module system, ECMAScript version, or language extension you want to use. In the previous example, we told ESLint how to interpret JSX files with languageOptions.parserOptions.ecmaFeatures.jsx property.

You can opt out of the latest ECMAScript version — e.g., ecmaVersion: 2015. ESLint also assumes that ESM is the way you handle JS modules in your project. Therefore, the default is sourceType: "module" for .js and .jsm files. Otherwise, you have to opt out (sourceType: "script"). For .cjs files, the default is sourceType: "commonjs".

Another useful property is languageOptions.globals. In projects for the browser environment, ESLint needs to know global variables like window or console. Otherwise, ESLint incorrectly reports a no-undef error: You can specify your project-specific global variables with languageOptions.globals. For browser projects, you can import globals, which is a JSON file holding predefined global identifiers:

import globals from "globals";
// ...
export default [
  {
    name: "globals",
    languageOptions: {
      globals: globals.browser,
    },
  },
  // ...
];

Again, you can utilize the Config Inspector to see all global variable names: You can read about all configuration capabilities in the official docs.

How to work with rules

For many projects, starting with a predefined rule set as provided by @eslint/js is a good choice. These sets provide a broad coverage of common issues and, if required, stylistic preferences.

When you run ESLint, either via CLI or the background process inside your code editor, rule violations are reported. For every violation, ESLint shows the rule ID (e.g., no-undef) and a short violation explanation.

With that rule ID, you can easily navigate to the rule detail page from the rules reference. Alternatively, from the VS Code extension (or any other code editor integration), you can click on the provided link: Every rule has an easy-to-read documentation page following the same structure, including a helpful TOC on the right: The rule details are handy for multiple reasons:

• Find out what the rule is all about
• Read about correct and incorrect code examples
• Examine all rule-specific options

The latter is relevant to finding out how to tweak the rule inside of eslint.config.

There’s an important concept called violation severities. Every rule has a default severity level. You can change the severity level for every rule in eslint.config. There are three levels of severity:

• off or 0 — Turn a rule off; i.e., ESLint will not check for this particular rule
• warn or 1 — A warning indicates a potential issue that, while not necessarily violating best practices or causing errors, might lead to confusion or less readable code. Warnings are meant to draw attention to something that might need review but most likely don't break anything. Warnings don't affect exit codes, meaning your CLI command will not be canceled
• error or 2 — An error indicates a significant issue that likely violates best practices or could lead to bugs. Errors are considered serious and should be addressed promptly. The CLI process does not terminate but exits with status code 1

To change a rule’s severity, set the rule ID equal to one of these values. The following example config demonstrates how to tweak different rules:

// eslint.config.js
import pluginJs from "@eslint/js";
// override default values
const modifiedRules = {
  // create a copy of the recommended rules to modify
 ...pluginJs.configs.recommended.rules,
 // turn rule off
 'no-unused-vars': 0,
 // Require the use of === and !== 
 // change default from error to warning
 'eqeqeq': 1,
 // Disallow the use of variables before they are defined.
 // Except for hoisted functions
 'no-use-before-define': ["error", { "functions": false }]
}
export default [
  {
    name: "ESLint recommended rules with modifications",
    rules: modifiedRules,
  },
];

The last example, no-use-before-define, demonstrates how to look up the options in the documentation and change them according to your preferences.

Most lint rules fall into one of two to three categories:

• Logical rules focus on the correctness and expected behavior of code during execution. Examples include ensuring promises are properly awaited
• Stylistic rules focus on the coding style you use that does not impact the runtime behavior, such as favoring one syntax variant over the other (e.g., function declarations vs. arrow functions)
• Formatting rules constitute a subset of stylistic rules that are solely concerned with code beautifying (e.g., use semicolons or not)

The use of stylistic rules falls into the scope of tools such as Prettier, which solely deal with code formatting. ESLint's stylistic rules (e.g., indent) may conflict with such dedicated formatters.

In October 2023, the ESLint team decided to deprecate all formatting rules, mainly for maintainability and architectural reasons. They have reserved the right to remove it from v10 onwards. You still have different options for combining ESLint with code formatting, as I will explain in the next section.

Later, we’ll discuss several options to use ESLint for code formatting.

Configuration comments

You've already seen one variant to configure rules inside of eslint.config. Alternatively, to configure rules inside of a file, you can leverage configuration comments:

/* eslint no-unused-vars: "off" */
let unusedVariable;
/* eslint eqeqeq: "warn" */
"hello world!" == "hello world"
/* eslint no-use-before-define: ["error", { "functions": false }] */
let x = usedBeforeDefined();
function usedBeforeDefined() {
  return true;
}

It's also possible to turn off rules with inline comments. This should only be used temporarily during development. Further, you should only commit these comments to VCS in exceptional cases. You can disable a rule for the whole file or the next line:

// the following disables the rule for the whole file
/* eslint-disable eqeqeq */
var testVar = "This should be 'let' or 'const'";
// eslint-disable-next-line no-undef
undefinedFunctionCall();
"hello world!" == "hello world"

You can also utilize the code editor integration to add these comments. With VS Code, you can right-click on ESLint errors or warnings and use the Quick Fix feature:

Rule suggestions and rule fixes

For a rule violation, your code editor may show a rule suggestion when you inspect the violation. In such a case, some problems reported by this rule are manually fixable by the code editor.

With the VS Code ESLint extension, you can do this from a context menu. When you browse through ESLint's Rules Reference, you can easily identify rules with suggestions by a bulb ? icon: Besides rule suggestions that require manual intervention of the developer to fix a violation, rule fixes safely correct violations automatically since they don't alter application logic. Every auto-fixable rule is marked with a wrench ? icon.

This feature is particularly useful for addressing common coding mistakes, formatting inconsistencies, and stylistic issues that adhere to predefined coding standards. To apply these automatic fixes, you can utilize the --fix option from the CLI:

$ npx eslint --fix

Later, we'll see how to establish a productive development workflow in your code editor to perform auto-fix on saving source files.

Utilizing shared community configurations

ESLint has a large community offering many publicly available configurations you can integrate via npm. These shared npm packages can contain one or more of the following concepts: configuration, rules, plugins, processors, and parsers. Here's how these concepts correlate:

• Configuration — The entire eslint.config file represents an ESLint configuration
• Rules — As covered in great detail above, shared rules are individual coding guidelines provided by the community, such as ESLint Config for standardjs.com
• Processors — Processors are required to extract JavaScript code from other kinds of files before linting (e.g., code inside of script tag in .vue files)
• Parsers — ESLint works internally with an Abstract Syntax Tree (AST) to statically lint source code. Custom parsers extend ESLint beyond the default parser (Espree) to support more JS language extensions (e.g., @typescript-eslint/parser to let ESLint understand TypeScript code)
• Plugins — Custom plugins extend ESLint's capabilities by bundling additional rules, custom configurations, custom parsers, and preprocessors. The official ESLint plugin for Vue provides Vue-specific rules and internally uses vue-eslint-parser to process .vue files

Over the years, many popular and widespread shared configurations have been developed. However, with every breaking change in ESLint, the community projects need to migrate. Therefore, it's important to check the compatibility with ESLint v9 support and flat config support in particular before using a third-party npm package: To use a shared ruleset, you can also leverage the CLI option --config. The following installs a third-party configuration, eslint-config-canonical:

$ npm init @eslint/config@latest -- --config eslint-config-canonical

Let's look at an example to install a shared plugin. To add Vue support, we have to install eslint-plugin-vue:

$ npm i -D eslint-plugin-vue

The following eslint.config integrates the recommended ESLint rules in addition to the recommended configuration of eslint-plugin-vue. Further, it overrides one of the available Vue rules:

// eslint.config.js
import pluginJs from "@eslint/js";
import pluginVue from "eslint-plugin-vue";
export default [
  { rules: pluginJs.configs.recommended.rules },
  ...pluginVue.configs["flat/recommended"],
  {
    // override default rule settings
    rules: {
      // change severity to warning
      "vue/no-reserved-props": "warn"
    },
  },
];

If you inspect pluginVue.configs["flat/recommended"], you find out that internally the plugin uses a dedicated processor and parser:

//...
module.exports = [
  // ...
  {
    name: 'vue:base:setup-for-vue',
    files: ['*.vue', '**/*.vue'],
    plugins: {
      // ...
    },
    languageOptions: {
      parser: require('vue-eslint-parser'),
      sourceType: 'module',
      globals: globals.browser
    },
    rules: {
      'vue/comment-directive': 'error',
      'vue/jsx-uses-vars': 'error'
    },
    processor: 'vue/vue'
  }
]

The ESLint config inspect also shows this fact for the entry vue:base:setup-for-vue:

Further reading:

• Reduce maintenance effort with shared ESLint and Prettier configs

Use cases for ESLint

This section explains a couple of use cases of using ESLint in projects.

Auto-fix ESLint issues on file save

Besides using the CLI option --fix, you can execute auto-fix from your code editor when you save a file. Then, all fixable rule violations in the file are automatically solved. This has multiple advantages:

• Immediate feedback and correction — Helps you learn and adhere to coding standards more quickly, as you see the consequences of your actions immediately
• Increased productivity — This workflow reduces the need to manually run ESLint from the CLI, which saves time and allows you to focus more on coding rather than fixing linting issues
• Consistent code quality — By fixing issues as soon as they are introduced, you maintain a higher level of code quality throughout the development process. This approach helps prevent the accumulation of linting errors, making it easier to manage and review code
• Reduced context switching — Reduces the need to switch between your editor and the terminal to run ESLint commands, helping you maintain your focus

This workflow is also very handy if you integrate ESLint with code formatting.

Further reading:

• Reduce maintenance effort with shared ESLint and Prettier configs

Handle code formatting issues

As already mentioned, the ESLint team has deprecated all formatting rules and recommends only using logical rules. You can still use these stylistic rules, although their usage is discouraged.

A better approach is to choose one of the two options to enable ESLint supporting code formatting.

The common approach is to integrate ESLint with dedicated code formatting tools, such as Prettier or dprint. For Prettier, the preferred way is to run Prettier as an ESLint rule with eslint-plugin-prettier.

The following steps are required to set this up. First, install all dependencies:

$ npm i -D eslint@latest @eslint/js globals eslint-plugin-prettier eslint-config-prettier prettier

Then, use the plugins in eslint.config.mjs:

import pluginJs from "@eslint/js";
import pluginPrettierRecommended from "eslint-plugin-prettier/recommended";
export default [
  {
    name: "ESLint recommended config",
    ...pluginJs.configs.recommended,
  },
  {
    name: "ESLint plugin for Prettier formatting",
    ...pluginPrettierRecommended,
  },
];

Next, the IDE integration is required. For VS Code, make sure to install the extensions for ESLint and Prettier.

Lastly, we need to configure the format on save for VS Code in .vscode/settings.json:

{
  "editor.formatOnSave": true,
  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": "explicit"
  }
}

The npm package eslint-config-prettier eventually disables any ESLint rules dealing with code formatting to avoid conflicts with Prettier. You can see this with the handy ESLint Config Inspector: The second option is to use ESLint Stylistic. The primary focus of this project is on all stylistic rules including code formatting. This project was initiated as ESLint and typescript-eslint teams decided to deprecate formatting/stylistic-related rules.

The following steps are required to use ESLint Stylistic:

$ npm i -D @stylistic/eslint-plugin-js

Then you need to include the plugin into your eslint.config:

import pluginJs from "@eslint/js";
import stylisticJs from "@stylistic/eslint-plugin-js";
export default [
  {
    name: "logical rules only",
    ...pluginJs.configs.recommended,
  },
  {
    plugins: {
      "@stylistic/js": stylisticJs,
    }
  }
];

Finally, you need the same .vscode/settings.json as explained above if you want to use the plugin with auto-fixing stylistic issues on save:

Further reading:

• Reduce maintenance effort with shared ESLint and Prettier configs

Using ESLint with Git hooks and in CI/CD pipelines

Using ESLint with Git commit hooks (with the help of tools like Husky and lint-staged) and within CI/CD pipelines serves complementary purposes to ensure code quality and consistency throughout the development lifecycle.

Integrating ESLint with Git commit hooks ensures that code is automatically linted before it is committed. This helps with catching and fixing linting errors early in the development process, preventing problematic code from entering the codebase. Tools like lint-staged help you to run ESLint only on changed files to improve DX.

As another safety net, you should also integrate ESLint into your CI/CD pipeline. In this section, we discussed how to integrate ESLint into your IDE, which means that ESLint runs on the current file you're working on. In your CI/CD environment, you should lint all your files for every pipeline run.

Further reading:

• Build a robust React app with Husky pre-commit hooks and GitHub Actions
• Developing an effective CI/CD pipeline for frontend apps

ESLint and its competitors

ESLint has been around for over 10 years. Over the years, there have been many competitors who have gradually lost favor with users. This section provides an overview of the field and how ESLint compares to its competitors.

La première génération de linters

Lancé comme l'un des premiers outils de linters pour JavaScript, JSLint est connu pour être l'ancêtre des linters JavaScript. Il est très avisé et ne prend pas en charge la configuration de règles personnalisées, établissant une norme de codage stricte sans possibilité de déviation.

Émergeant comme un fork de JSLint, JSHint a été introduit pour offrir aux développeurs plus d'options de configuration. Malgré cela, il reste moins flexible qu'ESLint, notamment en termes de personnalisation des règles et de prise en charge des plugins, limitant son adaptabilité aux divers besoins des projets. La dernière sortie remonte à 2022.

Initialement l'outil de peluchage incontournable pour TypeScript, TSLint est obsolète depuis 2019 au profit d'ESLint, qui a étendu ses capacités pour inclure TypeScript via des plugins. La dépréciation de TSLint a marqué un changement significatif dans la communauté TypeScript vers une solution de peluchage plus unifiée.

Se distinguant de ses pairs de première génération, ESLint est devenu l'outil dominant de l'écosystème JavaScript depuis 2013. Son succès est attribué à sa configurabilité étendue, à son écosystème de plugins et à la prise en charge de règles personnalisées, le rendant adaptable à un large éventail de fonctionnalités. des styles de codage et des exigences du projet.

Deuxième génération de linters (post-2020)

Le paysage des outils de peluchage JavaScript a considérablement évolué depuis les outils plus opiniâtres et rigides de la première génération jusqu'aux outils plus accessibles et axés sur les performances de la deuxième génération.

Dans le cadre de ces nouveaux linters, Biome a émergé au lendemain de la pandémie en 2020, mais sous le nom de Rome. Biome a été créé à la mi-2023 en tant que fork de Rome, qui est un projet actif soutenu par une communauté croissante. Biome se concentre sur une portée plus large, incluant le formatage du code en plus du peluchage. Concernant le linting, le support linguistique n'est pas encore à la hauteur de celui d'ESLint.

Lancé en 2021 avec la promesse d'améliorer le workflow des développeurs, quick-lint-js se positionne comme un outil complémentaire à ESLint. Il est conçu pour une « vitesse en temps réel », offrant un retour rapide dans votre éditeur de code sans latence. Un autre objectif de l’outil est la configuration zéro, il est donc opiniâtre. L'outil s'adresse à un groupe cible particulier.

Un entrant relativement nouveau, RSLint se concentre sur la fourniture d'un outil de peluchage sans configuration. Il en est aux premiers stades de développement et n’est pas prêt pour la production. La dernière version date de 2022, il n’est donc pas clair si le développement est toujours actif.

À partir de février 2023, oxlint n'est pas destiné à remplacer ESLint mais à le compléter, notamment dans les scénarios où les performances d'ESLint pourraient constituer un goulot d'étranglement. Il prend en charge JavaScript, TypeScript et certains frameworks ; par exemple, Vue.js.

En tant que linter pour le runtime Deno, deno lint prend en charge JavaScript et TypeScript de manière native. Son intégration avec Deno le distingue du reste du pack, s'adressant spécifiquement aux projets utilisant ce runtime.

Bien qu'ESLint reste la pierre angulaire du linting JavaScript, l'émergence de nouveaux outils reflète la recherche continue de la communauté en matière d'efficacité, de performance et d'adaptabilité aux besoins spécifiques des projets. Le résultat de l’impact de cette deuxième génération est encore en train de se dévoiler, avec de nombreux outils trouvant leur niche ou servant de compléments précieux aux capacités complètes d’ESLint.

Tableau comparatif : ESLint par rapport aux autres linters

Le tableau suivant compare ESLint avec ses concurrents actuels :

J'ai eu l'impression que l'équipe ESLint a pris certaines critiques au sérieux et les a résolues avec la version 9 — par exemple, des options par défaut plus judicieuses pour contrecarrer le besoin de configuration. Le billet de blog récemment publié confirme mon point de vue, car il reste encore des changements architecturaux majeurs à apporter au cœur d'ESLint, ce qui améliorera probablement encore les performances.

Des projets comme Biome sont certainement l'une des raisons pour lesquelles l'équipe ESLint a décidé de réaliser ces adaptations complexes. Certaines des raisons invoquées par les concurrents pour expliquer pourquoi leur propre solution est meilleure qu'ESLint sont déjà obsolètes.

Conclusion

Devriez-vous vous en tenir à ESLint comme outil de peluchage de votre choix ? Je recommande d'utiliser ESLint dans la plupart des cas d'utilisation, notamment dans un environnement commercial. ESLint est bien adopté et les développeurs savent probablement comment l'utiliser en raison de sa large distribution.

Même les projets concurrents ambitieux ne peuvent pas encore couvrir tous les cas d'utilisation dont les développeurs ont besoin. Par exemple, Biome ne prend pas entièrement en charge CSS ou Vue.js depuis juillet 2024. Il existe également d'autres voix de la communauté qui préconisent l'utilisation d'ESLint avec Prettier comme la meilleure combinaison pour le peluchage et le formatage.

Il y a toujours eu des critiques concernant la complexité et les performances d'ESLint. Cependant, une expérience concrète de projet au sein d'équipes de développement, sa très bonne documentation et ses outils sont de très bons arguments en faveur d'ESLint.

À moins que vous souhaitiez couvrir un cas d'utilisation très spécifique, tel que le retour en temps réel dans l'EDI (ce qui est possible avec quick-lint-js), ESLint couvre pratiquement tous les cas d'utilisation de développement pertinents grâce à son riche ensemble de fonctionnalités.

LogRocket : déboguez plus facilement les erreurs JavaScript en comprenant le contexte

Le débogage du code est toujours une tâche fastidieuse. Mais plus vous comprenez vos erreurs, plus il est facile de les corriger.

LogRocket vous permet de comprendre ces erreurs de manière nouvelle et unique. Notre solution de surveillance front-end suit l'engagement des utilisateurs avec vos frontends JavaScript pour vous donner la possibilité de voir exactement ce que l'utilisateur a fait qui a conduit à une erreur.

LogRocket enregistre les journaux de la console, les temps de chargement des pages, les traces de pile, les requêtes/réponses réseau lentes avec en-têtes + corps, les métadonnées du navigateur et les journaux personnalisés. Comprendre l'impact de votre code JavaScript n'aura jamais été aussi simple !

Essayez-le gratuitement.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!