eslint · Build et types
Le message
Parsing error: Unexpected token
Ce que cela veut dire
ESLint s'est arrêté à la lecture de la syntaxe, avant d'appliquer la moindre règle au fichier. Bien plus souvent qu'un code réellement cassé, cela signifie que l'analyseur ne connaît pas cette syntaxe : un fichier TypeScript lu par l'analyseur par défaut, du JSX jamais activé, ou des décorateurs et une syntaxe très récente confiés à un vieil analyseur. Lancer npx eslint --print-config app.ts sur ce fichier précis affiche quel parser et quelles parserOptions s'appliquent vraiment : commencez par là plutôt que de deviner. TypeScript exige @typescript-eslint/parser, et si le fichier ne doit pas être analysé du tout, le placer dans ignores est la bonne réponse.
Le correctif
npx eslint --print-config app.ts- Émis par
- eslint
- Build et types
- 10
Les erreurs de build sont un outil qui refuse avant toute exécution : elles ne cassent rien à l'instant où elles surgissent, mais elles posent deux questions — corrigerez-vous le type ou le chemin pour coller à la forme réelle, ou ferez-vous passer cette seule ligne avec un as any ou un commentaire de suppression ? Et c'est ici que se révèlent pour la première fois les choses qui ne sont vraies que sur votre machine : la casse, les extensions et les variables d'environnement.
Lire un message d’erreur
- Lisez à partir de la première ligne. Plus on descend, plus il s’agit des entrailles de l’outil ; la cause est généralement en haut.
- S’il y a un fichier et un numéro de ligne, commencez là — pas la première image de la pile, mais la ligne la plus haute qui nomme un fichier de vous.
- Cherchez le message tel quel, mais retirez d’abord vos chemins et vos noms de variables : c’est cela qui empêche la correspondance.
- La même situation se formule autrement selon la version de l’outil. Si les résultats sonnent faux, ajoutez le numéro de version.
- Avant de coller un correctif, vérifiez ce qu’il jette. Certains sont irréversibles.
Questions fréquentes
Q. Que veut dire « Parsing error: Unexpected token » ?
ESLint s'est arrêté à la lecture de la syntaxe, avant d'appliquer la moindre règle au fichier. Bien plus souvent qu'un code réellement cassé, cela signifie que l'analyseur ne connaît pas cette syntaxe : un fichier TypeScript lu par l'analyseur par défaut, du JSX jamais activé, ou des décorateurs et une syntaxe très récente confiés à un vieil analyseur. Lancer npx eslint --print-config app.ts sur ce fichier précis affiche quel parser et quelles parserOptions s'appliquent vraiment : commencez par là plutôt que de deviner. TypeScript exige @typescript-eslint/parser, et si le fichier ne doit pas être analysé du tout, le placer dans ignores est la bonne réponse.
Q. Comment le corriger ?
npx eslint --print-config app.ts — avant de le lancer, vérifiez plus haut ce que cette commande jette.
Q. Quel outil émet cela ?
eslint. Cela relève de Build et types, et le message compte 4 mots.