eslint
v9.15.0
Site Web | Configurer ESLint | Règles | Contribuer à ESLint | Signaler des bogues | Code de conduite | Twitter | Discorde | Mastodonte
ESLint est un outil permettant d'identifier et de créer des rapports sur les modèles trouvés dans le code ECMAScript/JavaScript. À bien des égards, il est similaire à JSLint et JSHint à quelques exceptions près :
Conditions préalables : Node.js ( ^18.18.0 , ^20.9.0 ou >=21.1.0 ) construit avec la prise en charge SSL. (Si vous utilisez une distribution Node.js officielle, SSL est toujours intégré.)
Vous pouvez installer et configurer ESLint à l'aide de cette commande :
npm init @eslint/config@latestAprès cela, vous pouvez exécuter ESLint sur n'importe quel fichier ou répertoire comme ceci :
npx eslint yourfile.js Vous pouvez configurer des règles dans vos fichiers eslint.config.js comme dans cet exemple :
export default [
{
files : [ "**/*.js" , "**/*.cjs" , "**/*.mjs" ] ,
rules : {
"prefer-const" : "warn" ,
"no-constant-binary-expression" : "error"
}
}
] ; Les noms "prefer-const" et "no-constant-binary-expression" sont les noms des règles dans ESLint. La première valeur est le niveau d'erreur de la règle et peut être l'une des valeurs suivantes :
"off" ou 0 - désactive la règle"warn" ou 1 - active la règle comme avertissement (n'affecte pas le code de sortie)"error" ou 2 - activez la règle comme une erreur (le code de sortie sera 1)Les trois niveaux d'erreur vous permettent un contrôle précis sur la manière dont ESLint applique les règles (pour plus d'options de configuration et de détails, consultez la documentation de configuration).
L'équipe ESLint fournit un support continu pour la version actuelle et six mois de support limité pour la version précédente. La prise en charge limitée inclut uniquement les corrections de bogues critiques, les problèmes de sécurité et les problèmes de compatibilité.
ESLint offre un support commercial pour les versions actuelles et précédentes via nos partenaires, Tidelift et HeroDevs.
Voir Prise en charge des versions pour plus de détails.
ESLint adhère au code de conduite de la Fondation OpenJS.
Avant de signaler un problème, assurez-vous de lire les directives relatives à ce que vous signalez :
Oui, ESLint prend en charge nativement l'analyse de la syntaxe JSX (cela doit être activé dans la configuration). Veuillez noter que la prise en charge de la syntaxe JSX n'est pas la même chose que la prise en charge de React. React applique une sémantique spécifique à la syntaxe JSX qu'ESLint ne reconnaît pas. Nous vous recommandons d'utiliser eslint-plugin-react si vous utilisez React et souhaitez la sémantique React.
Non, ESLint et Prettier ont des tâches différentes : ESLint est un linter (recherche de modèles problématiques) et Prettier est un formateur de code. L'utilisation des deux outils est courante, reportez-vous à la documentation de Prettier pour savoir comment les configurer pour qu'ils fonctionnent correctement l'un avec l'autre.
ESLint prend entièrement en charge ECMAScript 3, 5 et chaque année depuis 2015 jusqu'à la spécification de niveau 4 la plus récente (valeur par défaut). Vous pouvez définir la syntaxe ECMAScript souhaitée et d'autres paramètres (comme les variables globales) via la configuration.
L'analyseur d'ESLint ne prend officiellement en charge que la dernière norme ECMAScript finale. Nous apporterons des modifications aux règles de base afin d'éviter les plantages sur les propositions de syntaxe ECMAScript de l'étape 3 (à condition qu'elles soient implémentées en utilisant la syntaxe expérimentale ESTree correcte). Nous pouvons apporter des modifications aux règles de base pour mieux fonctionner avec les extensions de langage (telles que JSX, Flow et TypeScript) au cas par cas.
Dans d'autres cas (y compris si les règles doivent avertir sur plus ou moins de cas en raison d'une nouvelle syntaxe, plutôt que de simplement ne pas planter), nous vous recommandons d'utiliser d'autres analyseurs et/ou plugins de règles. Si vous utilisez Babel, vous pouvez utiliser @babel/eslint-parser et @babel/eslint-plugin pour utiliser n'importe quelle option disponible dans Babel.
Une fois qu'une fonctionnalité de langage a été adoptée dans la norme ECMAScript (étape 4 selon le processus TC39), nous accepterons les problèmes et les demandes d'extraction liés à la nouvelle fonctionnalité, sous réserve de nos directives de contribution. D'ici là, veuillez utiliser l'analyseur et le(s) plugin(s) approprié(s) pour votre fonctionnalité expérimentale.
ESLint met à jour les versions Node.js prises en charge avec chaque version majeure d'ESLint. À ce moment-là, les versions Node.js prises en charge par ESLint sont mises à jour pour être :
ESLint devrait également fonctionner avec les versions de Node.js publiées après la version actuelle de Node.js.
Reportez-vous au Guide de démarrage rapide pour connaître les versions Node.js officiellement prises en charge pour une version ESLint donnée.
Ouvrez une discussion ou arrêtez-vous sur notre serveur Discord.
Les fichiers de verrouillage comme package-lock.json sont utiles pour les applications déployées. Ils garantissent que les dépendances sont cohérentes entre les environnements et entre les déploiements.
Les packages comme eslint qui sont publiés dans le registre npm n'incluent pas de fichiers de verrouillage. npm install eslint en tant qu'utilisateur respectera les contraintes de version dans package.json d'ESLint. ESLint et ses dépendances seront inclus dans le fichier de verrouillage de l'utilisateur s'il en existe un, mais le propre fichier de verrouillage d'ESLint ne sera pas utilisé.
Nous ne verrouillons pas intentionnellement les versions de dépendances afin de disposer des dernières versions de dépendances compatibles en cours de développement et de CI que nos utilisateurs obtiennent lors de l'installation d'ESLint dans un projet.
Le blog Twilio propose une analyse plus approfondie pour en savoir plus.
Nous avons programmé des sorties toutes les deux semaines, le vendredi ou le samedi. Vous pouvez suivre un numéro de version pour obtenir des mises à jour sur la planification d'une version particulière.
ESLint prend la sécurité au sérieux. Nous travaillons dur pour garantir qu'ESLint est sûr pour tout le monde et que les problèmes de sécurité sont résolus rapidement et de manière responsable. Lisez la politique de sécurité complète.
ESLint suit le versioning sémantique. Cependant, en raison de la nature d'ESLint en tant qu'outil de qualité du code, il n'est pas toujours clair quand un changement de version mineur ou majeur se produit. Pour aider à clarifier cela pour tout le monde, nous avons défini la politique de version sémantique suivante pour ESLint :
eslint:recommended est mis à jour et entraînera strictement moins d'erreurs de peluchage (par exemple, suppressions de règles).eslint:recommended est mis à jour et peut entraîner de nouvelles erreurs de peluchage (par exemple, des ajouts de règles, la plupart des mises à jour d'options de règles). Conformément à notre politique, toute mise à jour mineure peut signaler plus d'erreurs de peluchage que la version précédente (ex : suite à une correction de bug). En tant que tel, nous vous recommandons d'utiliser le tilde ( ~ ) dans package.json par exemple "eslint": "~3.1.0" pour garantir les résultats de vos builds.
Les règles stylistiques sont gelées conformément à notre politique sur la façon dont nous évaluons les nouvelles règles et les modifications de règles. Cela signifie:
Ces personnes font avancer le projet et constituent des ressources d’aide.
Les personnes qui gèrent les versions, examinent les demandes de fonctionnalités et se réunissent régulièrement pour garantir qu'ESLint est correctement entretenu.
