La politique d'installation se met en règle, et neuf paquets montent

[Shaenn]

Deux lots, dans cet ordre : la politique d'installation d'abord, les montées ensuite. L'ordre compte — les montées passent sous la politique que les premiers commits posent, et non l'inverse.

---

I. La politique d'installation

Épingler pnpm

Le projet ne déclarait pas de packageManager. Rien ne garantissait donc sous quelle version de pnpm il s'installe — et la quarantaine du workspace en dépend : strictDepBuilds et le caractère strict de minimumReleaseAge ne valent que sous pnpm 11. Une installation sous pnpm 10 les aurait ignorés en silence.

Le champ est posé sans somme de contrôle. corepack use l'aurait inscrite, et elle immobilise le fichier à chaque correctif de pnpm.

L'override de vite

Le relevé le donnait pour non documenté. Il l'était déjà, depuis 466df7c : l'avis de sécurité, la ligne 5 de Vite jamais corrigée, et pourquoi la portée est vitepress>vite et non vite. Manquait seulement ce qui permettrait de le retirer — sans quoi un override traverse les montées de version par inertie, faute de savoir quand le tester à la suppression. C'est ce qui est ajouté.

Ce que l'épinglage a fait tomber

Poser packageManager a cassé la CI, et l'a cassée à la première étape : pnpm/action-setup a trouvé deux sources pour la même version — version: 11 dans le workflow, pnpm@11.18.0 dans package.json — et refuse de démarrer sur le doublon sans comparer les numéros, qui pourtant s'accordaient. Les deux workflows laissent désormais package.json répondre seul.

Le socle exigé, remis d'accord

engines.pnpm restait à ">= 10.0.0" : la borne autorisait par écrit ce que packageManager interdit de fait. Elle passe à ">= 11.18.0 <12" — plancher accordé à la version épinglée, plafond excluant la 12, dont on ne connaît pas encore le sort réservé à minimumReleaseAgeStrict.

La contradiction ne vivait pas que dans package.json — six documents annonçaient pnpm ≥ 10 comme prérequis : les deux INSTALL, les deux README, les deux pages d'accueil du site. Tous alignés. site/guide/ n'est pas touché, il est généré.

Ce que le manifeste refuse désormais

Les 38 dépendances étaient déclarées en plages : une montée pouvait arriver par un simple pnpm install, sans jamais apparaître au diff. Elles sont épinglées à la version réellement installée — donc @vue/eslint-config-typescript à 14.9.0 et vue-eslint-parser à 10.4.1, et non à la base de leur plage, qui aurait été un retour en arrière. savePrefix: '' empêche pnpm add de réintroduire un ^ un paquet à la fois.

engines ne nomme plus npm ni yarn : le projet ne s'installe pas autrement, son lockfile est celui de pnpm. engineStrict: true donne enfin un effet à ce champ, qui restait un vœu — pnpm avertissait et poursuivait.

Deux overrides s'ajoutent, parce qu'une épingle ne tient pas ce qu'un override tient — ni les transitives, ni le premier pnpm up --latest :

• typescript: '<7' — TypeScript 7 a retiré l'API programmatique du compilateur, sur laquelle repose vue-tsc. La montée ne casse pas un type ici ou là, elle casse pnpm typecheck en entier.
• '@types/node': '<25' — au-delà de la 24, les types décrivent des API absentes du runtime qu'on exécute : le code compile et échoue à l'exécution.

Chacun porte sa raison et sa condition de retrait, comme celui de vite.

Le hoisting

shamefullyHoist: true équivaut à publicHoistPattern: '*' : le projet accède à des paquets qu'il n'a jamais déclarés, et une dépendance retirée d'un manifeste continue de fonctionner jusqu'au jour où elle disparaît de l'arbre. Remplacé par les deux motifs dont le build a réellement besoin — @fontsource/* et vite —, puis vérifié par un build complet des deux chaînes, l'application et la vitrine.

---

II. Les montées

Neuf paquets, un commit chacun, lint + typecheck + 518 tests après chacun, et le build là où il porte.

paquet	de → vers
@quasar/extras	2.0.3 → 2.0.4	correctif
dompurify	3.4.13 → 3.4.14	correctif
fastify	5.12.0 → 5.12.1	correctif
mermaid	11.16.1 → 11.17.0	mineur
quasar	2.24.0 → 2.25.1	mineur
@quasar/app-vite	3.5.0 → 3.7.0	mineur
concurrently	10.0.4 → 10.0.5	correctif
vitest	4.1.10 → 4.1.11	correctif
vue-tsc	3.3.9 → 3.3.10	correctif

Aucun avertissement nouveau au build. Le seul qui apparaisse est celui de taille de chunk, déjà présent avant le lot.

Deux d'entre elles ne se sont pas laissé faire seules.

quasar 2.25.1 casse le build, et c'est un défaut amont

Quasar type ses packs de langue à deux endroits qui ont cessé de se rejoindre :

fichier	ce qu'il décrit	signature
lang.d.ts	un pack — ce que rend import('quasar/lang/fr')	prevRangeYears?: (range: number) => string
index.d.ts	le paramètre de Lang.set()	prevRangeYears: (range?: number) => string

Les libellés d'accessibilité ajoutés à q-date en 2.25 y arrivent dans deux formes incompatibles : optionnelle d'un côté, requise de l'autre ; paramètre requis d'un côté, optionnel de l'autre. Sous exactOptionalPropertyTypes — actif côté src/ seulement, ce qui explique que pnpm typecheck n'en dise rien —, l'un cesse d'être assignable à l'autre, et pnpm build s'arrête sur src/i18n/apply.ts.

L'objet importé est pourtant exactement celui que Lang.set attend à l'exécution. Le type du paramètre est donc dérivé de la fonction elle-même plutôt que réécrit à la main :

type QuasarLangPack = Parameters<typeof Lang.set>[0];

Le choix compte : un as never aurait tout tu, y compris un vrai changement de forme. Ici, si Quasar modifie ce que Lang.set accepte, l'erreur revient.

Vérifié à l'exécution, pas seulement à la compilation — un cast se juge sur le comportement. Les packs 2.25.1 portent bien les nouveaux libellés (fr.date.prevRangeYears(20) rend « Précédent 20 années »), et dans le navigateur, sur la SPA bâtie, la bascule de langue pose lang="fr" → lang="en-US" → lang="fr" sur le document, sans une erreur en console. L'attribut en-US est la marque que Lang.set a repris la main : le pack est chargé et appliqué.

@quasar/app-vite 3.7.0 déplace un train de transitives

La chaîne d'outils les tient en plages, et la montée les emporte : sass et sass-embedded en 1.103.1, vite en 8.2.2, rolldown en 1.2.5, open en 11.0.1. Deux paquets entrent dans l'arbre par open — powershell-utils et wsl-utils. Aucun n'exécute de script d'installation ; strictDepBuilds l'aurait refusé. C'est le seul commit du lot dont le lockfile bouge largement.

Ce qui n'est pas monté

@anthropic-ai/claude-agent-sdk reste en 0.3.233, écarté volontairement : sa version est verrouillée au CLI qu'elle embarque, et cela se juge en la faisant émettre, pas en la compilant. C'est le seul écart du relevé encore ouvert.

---

Vérification

CI verte sur le lot complet : pnpm install --frozen-lockfile, lint, typecheck, tests, build. Le lockfile figé passe donc aussi dans un environnement neuf, ce qui valide engineStrict et les nouveaux overrides ailleurs que sur la machine de développement.

En local, s'ajoutent le build de la vitrine, le démarrage du BFF — écoute confirmée sur 127.0.0.1 —, et la vérification navigateur ci-dessus.

pnpm-workspace.yaml n'a vu réapparaître aucune ligne : pas de minimumReleaseAgeExclude, pas de neverBuiltDependencies. La quarantaine tient, aucune dérogation n'a été nécessaire.

À trancher

Le CHANGELOG définit le majeur comme « ce qui casse une installation qui marchait : socle exigé relevé ». Relever engines.pnpm de 10 à 11 entre dans cette définition à la lettre, et engineStrict transforme la borne en refus effectif — ce qui rend la question plus tranchante qu'au premier jet. L'argument contraire : le socle relevé est celui de l'outil qui construit AURA, pas celui qui la fait tourner.

À fusionner par merge commit : les correctifs commités un par un doivent rester lisibles.

🤖 Generated with Claude Code