@luxflow/eslint-config

Configuration ESLint partagée du monorepo LuxFlow. Trois couches, chacune sur-ensemble strict de la précédente, parce que les consommateurs réels sont de trois natures.

| couche | ce qu'elle ajoute | pour | |---|---|---| | @luxflow | ESLint + TypeScript, env.node | cli, workspace, validation, distribution, run-generator, workflow-first, distribution-assembler | | @luxflow/eslint-config/react | eslint-plugin-react, eslint-plugin-react-hooks, env.browser | sections, ui — du React sans Next | | @luxflow/eslint-config/next | @next/eslint-plugin-next (recommended + core-web-vitals) | les 21 templates de factory/templates |

{ "extends": ["@luxflow"] }
{ "extends": ["@luxflow/eslint-config/react"] }
{ "extends": ["@luxflow/eslint-config/next"] }

Les trois plugins React/Next sont des peer dependencies optionnelles : un paquet Node qui n'utilise que la couche de base ne les installe pas.

Pourquoi les couches sont séparées

ui et sections sont du React sans Next. Leur donner les règles @next/next produirait, à chaque exécution, le message « Pages directory cannot be found » que no-html-link-for-pages écrit sur stderr quand il ne trouve pas de répertoire pages/ — un bruit permanent pour une règle qui, chez eux, ne peut rien détecter. Mesuré, pas supposé.

Pourquoi assemblé à la main, et pas eslint-config-next

Mesuré en T-068 lot 2, sur les 372 fichiers des 21 templates :

socle @luxflow seul               69 constats   ← aveugle à React
socle + eslint-config-next@14     84 constats
socle + cet assemblage            84 constats   ← identiques, règle par règle

La détection ne départage pas. Trois choses départagent :

1. eslint-config-next@16 exige ESLint ≥ 9 et la flat config. Le dépôt est en ESLint 8 / eslintrc : seule la branche 14 entre. Adosser des templates Next à une branche figée, c'est écrire une incohérence dès le premier jour. Voir T-077, qui rouvrira la question sur un terrain où eslint-config-next serait enfin cohérent.
2. Coût mesuré au verrou du dépôt : eslint-config-next@14 = +156 paquets (dont un napi-postinstall) ; cet assemblage = +124. Dans un dépôt destiné à la revente, c'est du temps d'installation et de la surface d'audit chez le client.
3. eslint-config-next impose ses settings, dont celui qui produit le bruit stderr ci-dessus.

Pourquoi ce nom

ESLint résout un nom scopé @scope en @scope/eslint-config. Un paquet nommé @luxflow/config-eslint serait cherché sous @luxflow/eslint-config-config-eslint — vérifié, ESLint refuse avec « couldn't find the config to extend from ». Le nom suit donc la convention de l'outil, pas notre préférence.

Pourquoi un paquet plutôt qu'un fichier racine

Un template de factory/ est une graine : le jour où il est copié pour devenir un projet, il emporte sa configuration. Un fichier racine du monorepo ne le suivrait pas, et le projet généré n'aurait aucun lint. Un paquet, si — il part comme dépendance.

Ce paquet n'est pas publié sur npm (404 vérifié le 21/08/2026). Les 21 templates le déclarent en workspace:* ; le générateur (T-075) devra soit le publier, soit inliner la configuration au moment de la copie. Suivi dans T-076.