ESLint : la validation de notre code front

La configuration est décrite en couches dans docs/front_code_validation.md du standard-bundle. Le socle est agnostique, chaque section suivante ajoute ce qu'un contexte exige.

yarn add --dev eslint @eslint/js eslint-config-prettier prettier

Les scripts du package.json :

"scripts": {
  "lint": "eslint . --fix --cache",
  "lint:check": "eslint .",
  "lint:baseline": "rm -f eslint-suppressions.json && eslint . --suppress-all",
  "format": "prettier --write .",
  "format:check": "prettier --check .",
  "validation": "yarn lint:check; s=$?; yarn format:check && exit $s"
}

• Un verbe nu corrige, :check ne fait que rapporter. La CI appelle les :check.
• validation enchaîne les deux contrôles, affiche les deux rapports, et échoue si l'un des deux échoue.
• --cache écrit un .eslintcache, à ajouter au .gitignore.

prettier.config.mjs :

export default {
  semi: false,
  singleQuote: false,
  printWidth: 100,
  singleAttributePerLine: true,
}

Toute option absente est un défaut de Prettier (tabWidth: 2, trailingComma: "all", ...). Le motif de chacune des quatre est sur cette page, section Prettier.

eslint.config.mjs :

import js from "@eslint/js"
import { defineConfig } from "eslint/config"
import skipFormatting from "eslint-config-prettier/flat"

export default defineConfig([
  { name: "app/files-to-lint", files: ["**/*.{js,mjs}"] },
  js.configs.recommended,
  skipFormatting,
])

• files déclare les extensions qu'ESLint prend quand on lui passe un répertoire : sans lui, seul .js est analysé. Les couches suivantes y ajoutent .vue et .ts.
• skipFormatting reste en dernier : sur une règle partagée, la dernière configuration gagne.

eslint-config-prettier désactive chaque règle ESLint qui doublonne ou contredit Prettier, règles de base et règles de mise en page du plugin Vue comprises. Son CLI vérifie qu'il n'en reste aucune :

npx eslint-config-prettier <fichier.js> <fichier.vue>

Il affiche No rules that are unnecessary or conflict with Prettier were found. quand tout est en ordre. Passer un fichier de chaque extension gérée par la configuration (.js, .vue, .ts) pour que toutes les règles soient comparées.

Nous importons eslint-config-prettier/flat directement, et non @vue/eslint-config-prettier/skip-formatting : le paquet Vue était un paquet de transition, sans maintenance prévue, et create-vue a fait le même changement début 2026 (PR #897).

yarn add --dev eslint-plugin-vue vue-eslint-parser

vue-eslint-parser, qui découpe un fichier .vue pour exposer son template et son script à ESLint, est une dépendance pair de eslint-plugin-vue : avec yarn, elle doit être déclarée explicitement.

import pluginVue from "eslint-plugin-vue"

  { name: "app/files-to-lint", files: ["**/*.{js,mjs,vue}"] },
  // ...
  ...pluginVue.configs["flat/strongly-recommended-error"],

Pourquoi strongly-recommended-error. essential, le défaut de create-vue, n'attrape que les erreurs. strongly-recommended ajoute les règles de cohérence dont l'absence laisse l'écriture des composants dériver :

• vue/prop-name-casing : props en camelCase ;
• vue/v-on-event-hyphenation : événements avec tirets dans les templates ;
• vue/require-default-prop : une valeur par défaut pour chaque prop optionnelle (default: undefined quand aucune n'a de sens).

La variante -error est nécessaire : le preset déclare ces règles en warn, qu'aucune baseline ne retient et qui ne font jamais échouer lint:check.

Ses 12 règles de mise en page ne gênent pas Prettier : 11 sont désactivées par skipFormatting, et vue/first-attribute-linebreak exige ce que Prettier produit déjà.

Pourquoi pas recommended. Il ajoute 8 règles, qui remontent 752 violations mesurées sur deux de nos bases de code. 84 % viennent de vue/attributes-order, une convention d'ordre dans la balise qui obligerait à réécrire tous les templates sans gain fonctionnel, et que le style guide Vue lui-même classe en priorité C. L'essentiel du reste est vue/no-v-html, alors que nos v-html affichent du contenu back-end que nous maîtrisons.

Symfony. Les commandes ciblent assets/ et les fichiers JS de la racine, jamais vendor/ : un bundle valide son propre code front depuis son propre dépôt. Le code front tourne dans le navigateur, les fichiers de configuration sous Node, et Twig injecte des globals qu'il faut déclarer :

import globals from "globals"

  {
    name: "app/globals-browser",
    languageOptions: {
      globals: {
        ...globals.browser,
        // Adapter of Ziggy's `route` function to FOSJsRoutingBundle, set on `window` by the Twig layout.
        route: "readonly",
      },
    },
  },
  {
    name: "app/globals-node",
    files: ["**/*.config.{js,mjs}"],
    languageOptions: { globals: { ...globals.node } },
  },

Inertia. Une page et son layout ne sont pas des composants réutilisables : résolus par leur chemin, ils reçoivent leurs props du contrôleur Symfony. Deux règles n'y ont pas d'objet, les composants y restent soumis :

  {
    name: "app/inertia-pages-and-layouts",
    files: ["**/scripts/pages/**/*.vue", "**/scripts/layout/**/*.vue"],
    rules: {
      "vue/multi-word-component-names": "off",
      "vue/require-default-prop": "off",
    },
  },

Tailwind CSS. prettier-plugin-tailwindcss, toujours en dernier dans la liste des plugins Prettier. Sur Tailwind 4, le thème vit dans le CSS : tailwindStylesheet donne au trieur le fichier d'entrée, sans quoi les utilitaires du design system (bg-primary, text-danger) sont rangés parmi les classes inconnues. Une entrée CSS par interface se déclare via overrides.

  plugins: ["prettier-plugin-tailwindcss"],
  tailwindStylesheet: "./assets/styles/app.css",

TypeScript. @vue/eslint-config-typescript branche typescript-eslint sur les fichiers .vue ; defineConfigWithVueTs remplace defineConfig pour propager le parser aux blocs <script>. La vérification des types reste hors ESLint : vue-tsc --build.

import { defineConfigWithVueTs, vueTsConfigs } from "@vue/eslint-config-typescript"

export default defineConfigWithVueTs(
  { name: "app/files-to-lint", files: ["**/*.{ts,mts,vue}"] },
  // ...
  vueTsConfigs.recommended,
  // ...
)

Les deux outils remontent beaucoup sur une base de code qui ne les a jamais eus. Plutôt qu'un big bang, chacun a sa façon de n'échouer que sur le code nouveau.

ESLint : la baseline. Les suppressions en masse : eslint-suppressions.json compte les violations existantes par fichier et par règle, seules les nouvelles font échouer.

• yarn lint:baseline régénère le fichier de zéro (--suppress-all ne retire jamais d'entrée). Relire son diff avant de commiter.
• Violation corrigée → entrée obsolète → lint:check sort en code 2 → régénérer.
• Seules les règles en error sont enregistrées.

Prettier : le pragma. Pas de baseline, mais requirePragma: true restreint Prettier aux fichiers qui commencent par @format :

• Faire entrer un fichier : yarn prettier --write --no-require-pragma --insert-pragma <fichiers> (--insert-pragma seul ne fait rien, requirePragma l'emporte).
• Marqueur : <!-- @format --> dans un .vue, /** @format */ dans un .js ou un .css.
• Puis yarn lint:baseline : le formatage corrige vue/first-attribute-linebreak, ses entrées deviennent obsolètes.
• Retirer l'option quand tout est formaté.

Prettier : le commit unique. Formater tout d'un coup est l'autre voie, la seule qui supprime le pragma tout de suite. Elle convient à un projet avec peu de fichiers front, peu de personnes et peu de branches ouvertes : chacune devra être rebasée sur les fichiers reformatés.

1. Commiter la configuration, fusionner les branches ouvertes.
2. Un commit avec yarn format, rien d'autre.
3. Filet : prettier --debug-check sur le même périmètre signale tout fichier dont le sens pourrait changer.
4. Une fois fusionné (squash ou rebase change le hash), inscrire le hash dans .git-blame-ignore-revs. Chaque développeur configure git config blame.ignoreRevsFile .git-blame-ignore-revs (PhpStorm le suit). GitLab : Blame preferences › Ignore specific revisions.

Pièges : fichiers entiers seulement, aucun outil maintenu ne formate les lignes modifiées ; un texte déplacé sur sa propre ligne dans un template devient un espace de bord une fois compilé par Vue, invisible dans un bloc, visible sous whitespace-pre-wrap ou <pre> ; blame.ignoreRevsFile configuré et fichier absent sur une branche → git blame échoue.

Ensuite. La résorption des suppressions et des fichiers sans pragma entre dans le flux non prioritaire de la maintenance technique, entre deux demandes. Un projet neuf n'a ni baseline ni pragma : les deux contrôles passent dès le premier commit.