# PRNext 0.1.21 : Flight, cache et builds mieux préparés PRNext 0.1.21-alpha est disponible sur npm. Cette version s’attaque au travail que l’on peut éviter sans changer ce que rend une application. Les hôtes de rendu peuvent préparer le framework avant leur première requête dynamique, les builds conservent de petits résumés vérifiés au lieu de réanalyser les fichiers inchangés, et les résultats primitifs en cache empruntent un format privé compact. Les valeurs React riches gardent leur décodage Flight officiel. Cette version renforce aussi la frontière entre la requête publique, le proxy directement connecté et les services de contrôle locaux. Elle prolonge 0.1.20 sans introduire de cache de réponses entre utilisateurs. L’application conserve la responsabilité de ses autorisations, de la durée de vie de ses données et de sa procédure de déploiement. ## Préparer chaque hôte avant la première réponse dynamique L’option explicite --prewarm prépare chaque hôte de rendu, puis applique la même préparation aux remplacements et aux réveils après inactivité. Deux préparations au maximum s’exécutent ensemble dans le budget initial de 15 secondes. Un petit modèle RSC et HTML interne exerce le renderer officiel sans importer une route applicative ni lire de données de compte. La disponibilité initiale attend cette préparation. Les imports applicatifs, connexions aux bases et données de requête peuvent encore ajouter du travail au premier vrai rendu. Un remplacement ultérieur qui ne termine pas sa préparation produit un diagnostic et conserve le chargement paresseux pour les requêtes ordinaires. Le démarrage paresseux reste le défaut, sans rejouer une requête applicative en échec. Mesurez le démarrage et la première réponse dynamique plutôt que de déduire d’un fichier statique disponible que React est prêt. ```sh npx --no-install prnext start --workers 2 --prewarm ``` ## Allouer moins autour de la même réponse Flight Les enveloppes de transport Flight et leurs tableaux de transfert sont réutilisés uniquement au sein de leur réponse, puis libèrent les références aux buffers après transfert. Les gros scripts d’amorçage inline sont encodés directement dans des buffers bornés. Les optimisations suivantes retardent aussi certaines allocations jusqu’à leur utilisation et empruntent un chemin direct pour les fragments HTML ordinaires complets. Le contenu encodé, le base64 et le nonce CSP conservent leur sens. Annulation, crédits de lecture, copies défensives des données appartenant à un producteur externe et séparation des réponses restent en place. Les attributs entre guillemets et les cas HTML ambigus gardent le parseur. Ces changements retirent du travail autour du transport sans conserver une réponse privée pour une autre requête. ## Observer la taille de Flight et la progression du renderer L’inspection activée explicitement regroupe les octets, chunks et statuts de fin Flight par motif de route et phase de rendu. Elle distingue les échantillons terminés, annulés, en échec et expirés, et expose les jalons de modèle et de shell prêts lorsqu’ils sont observés. RSC et SSR peuvent voir le même contenu : leurs tailles et nombres de requêtes ne doivent pas être additionnés. Ces durées comprennent le travail applicatif et les attentes asynchrones, pas seulement le CPU de l’encodeur ou du décodeur. Une mesure absente reste absente. Les diagnostics excluent le corps des réponses, cookies, autorisations et données brutes de recherche. Les observations optionnelles du GC, du heap et de la boucle d’événements apportent une autre lecture, sans observateur GC lorsqu’elles sont désactivées. Les réglages V8 par défaut et les options explicites de l’opérateur restent inchangés. ```sh npx --no-install prnext start . --inspect npx --no-install prnext inspect --json ``` ## Réutiliser les faits du build sans retirer ses contrôles Les builds répétés peuvent réutiliser des résumés Oxc typés et bornés contenant les directives et exports utiles aux étapes suivantes. Ces résumés immuables ne gardent ni texte source, ni AST, ni fermeture applicative. Les contrôles d’identité et de génération décident toujours si un enregistrement correspond à l’entrée courante ; une entrée absente ou invalide renvoie au travail normal. La découverte des dépendances natives réutilise aussi des preuves limitées lorsque le graphe est établi comme exempt de code natif. Les effets inconnus, hooks personnalisés et entrées modifiées conservent leurs contrôles. Le framework ne réutilise pas aveuglément un snapshot de graphe opaque. Les applications et outils de référence reçoivent également des mises à jour ciblées, dont les bases Next 16.4.4, Better Auth 1.7.15 et le client Redis 6.3.1. ## Borner les écritures et comprendre les phases de build Les copies du traçage standalone et du runtime utilisent une concurrence bornée, avec des alias traités dans un ordre déterministe et des budgets d’admission. Un changement de source pendant une copie reste détectable. En cas d’échec, les écritures déjà lancées se terminent avant l’abandon du stage temporaire ; le dernier build publié est préservé. Les chunks serveur Pages et leurs source maps sont réécrits en mémoire avant leur première écriture. build --timings expose les phases React pour distinguer une étape de compilation lente du travail sur les fichiers. Le total exclut le démarrage des modules CLI et les phases imbriquées se recouvrent : les additionner compterait certains travaux deux fois. Les rapports restent hors des manifestes de déploiement et des assets navigateur. ```sh npx --no-install prnext build --timings ``` ## Laisser React piloter les valeurs en cache et la continuation PPR Un callback en cache entre toujours une fois dans le renderer React officiel, avec son contexte React.cache. Les résultats primitifs éligibles utilisent un format privé compact et versionné. Objets, nœuds React, fonctions et références temporaires gardent le chemin Flight canonique, avec les octets d’origine pour les résultats riches ordinaires. Les chaînes contenant un BOM, de l’UTF-16 mal formé ou des valeurs proches de la limite de rendu conservent aussi le traitement Flight officiel. Les portées privées de requête, tags, TTL et nouveaux objets décodés sont préservés. Le changement concerne le codec de résultat, pas un nouveau cache entre comptes. Pour PPR natif, une analyse immuable et bornée ainsi que les informations de préfixe peuvent être réutilisées seulement après une nouvelle vérification des octets et du SHA de l’artefact courant. Les continuations mutables sont clonées par requête. Les continuations imbriquées ou non directes gardent leur normalisation existante lorsqu’elle est nécessaire. Les entrées RSC utilisent aussi un nouvel espace de clés. Après la mise à jour, les anciens résultats ne sont pas réutilisés : les premiers appels reconstituent les caches éligibles, ce qui doit entrer dans votre observation du réchauffement. ## Sortir les demandes abandonnées de la file de compilation Une requête de développement expirée ou annulée ne maintient plus sa demande de compilation en attente. Une compilation partagée déjà nécessaire à un autre appelant conserve son propre cycle de vie. Cette distinction évite de travailler uniquement pour une requête déconnectée sans annuler un travail encore utile à un autre onglet. Les notifications RPC de développement restent également la référence après leur première publication acceptée. Un snapshot de fichier tardif ne peut plus rétablir un diagnostic déjà effacé par RPC. Les notifications uniquement sur fichier restent disponibles jusqu’à l’établissement du RPC, sans mélanger les anciennes générations. En développement, les navigations successives et Fast Refresh coordonnent aussi leurs flux Flight. Une réponse encore en cours peut céder la place à la route suivante sans restaurer un ancien arbre et perdre l’état du layout partagé. Le changement vise les requêtes GET de développement, sans rejouer de mutation ; les réponses de production et les Server Actions gardent leur décodage strict. Avec navigationCache.authCookies configuré pour les cookies de session, la réautorisation garde la priorité : les brouillons d’un utilisateur ne sont pas réutilisés pour un autre. Une Server Action peut aussi remplacer la vue pendant la confirmation d’une mise à jour déjà appliquée. Fast Refresh distingue désormais ce remplacement de l’annulation de la mise à jour. Les véritables erreurs, annulations et délais réseau restent des échecs, sans renvoyer l’Action. Cette intégration de développement reste liée à la version React qualifiée avec PRNext. Elle utilise une option expérimentale du client Flight, sans activer ce comportement en production. ## Qualifier Node 26 avec les mêmes artefacts applicatifs La CI Linux ajoute des contrôles Node 26 pour le runtime et HTTP, Chromium, le SaaS et les consommateurs du package, avec installations hoistées et imbriquées. Cette couverture navigateur concerne Chromium. Elle ne remplace ni la matrice principale Linux, macOS et Windows ni le choix de Node dans un déploiement. Une couverture fonctionnelle ne donne pas un chiffre de débit pour Node 26. Comparez un changement de runtime avec les mêmes artefacts et dépendances, puis vérifiez vos propres parcours. Aucun gain chiffré Node 26 n’est attribué à cette campagne, qui utilise Node 22.23.4. ## Lire chaque mesure dans son périmètre réel Le comparatif contrôlé de la source publiée 0.1.20 à la source candidate 7c15132a s’exécute sous Linux x64 avec Node 22.23.4. Il comprend douze paires par route et 72 fenêtres au total, avec deux workers, des limites visibles de deux CPU et 5 Gio, et une affinité sur ces deux CPU. Chaque fenêtre dure quinze secondes après deux secondes de préchauffage, avec huit connexions SSR, deux pour l’API JSON et huit pour le streaming. La mesure compte 774 665 réponses utiles terminées dans les fenêtres, et 775 089 avec la vidange. Les 424 réponses de vidange ne contribuent pas au débit. Les compteurs d’erreurs HTTP, transport et validation sont nuls. Le préchauffage est compté séparément : 51 123 réponses dans ses fenêtres et 51 552 avec sa vidange. Les rapports médians appariés candidat/référence sont 0,9944 pour le débit SSR, 0,9941 pour l’API JSON et 0,9978 pour le streaming. Pour le p95, ils sont respectivement 1,0361, 1,0056 et 1,0028. Tous les intervalles appariés rapportés incluent 1. Les budgets fixés avant la mesure, une baisse de débit de 10 % au maximum et une hausse du p95 de 15 % au maximum, sont respectés. Ces résultats proches de la référence ne démontrent pas une accélération générale. L’archive JavaScript de référence correspond exactement à celle publiée pour 0.1.20, et celle du candidat à la qualification Linux de cette source. Les deux exécutables natifs ont toutefois été reconstruits séparément : ils ne sont pas les octets exacts des archives natives publiques ou de la qualification de release. Le résultat compare ces assemblages associés aux sources, sans isoler les changements JavaScript. Les observations kernel et de processus sont vérifiées pour les 72 échantillons. La mémoire reste échantillonnée, les limites parentes masquées et la contention du runner restent hors de cette vérification, et les autres dépendances de build ou transitives ne sont pas toutes certifiées octet par octet. Ces trois charges synthétiques ne prouvent ni une baisse globale de CPU ou de RAM, ni une capacité de production, ni un SLA. ## Garder des frontières explicites pour l’origine et le contrôle local La politique enregistrée d’origine publique et de proxys de confiance s’applique désormais aux entrées de développement, persistantes et natives multi-applications, y compris aux transferts HTTP et WebSocket. PRNext examine le pair réellement connecté avant d’accepter l’autorité ou le protocole transmis. Une origine canonique configurée reste prioritaire ; faire confiance à un proxy ne certifie toujours pas toute une chaîne d’adresses IP client. Les URL de repli des images sont construites par composants, puis leur origine normalisée finale est vérifiée avant toute exemption de requête interne. Le RPC du compilateur et du superviseur authentifie les deux extrémités et lie des nonces frais aux octets exacts des commandes et réponses. Les messages et délais restent bornés. Ce changement de protocole rend indispensable l’arrêt de l’ancien superviseur avant la mise à jour. ## Arrêter l’ancien superviseur avant de remplacer sa CLI Si vous utilisez le superviseur persistant, inspectez-le puis arrêtez-le avec l’ancienne CLI encore installée, sous le même PRNEXT_PM_HOME, avant de remplacer les paquets. pdown concerne le superviseur et toutes les applications gérées qui partagent ce répertoire : planifiez leur maintenance ensemble. Une mise à jour de la CLI globale ne remplace pas chaque runtime applicatif. Conservez sources, lockfile, configuration, build et sauvegarde compatible de base de données pour le retour arrière. ```sh npx --no-install prnext pstatus --json npx --no-install prnext pdown npm install @thomas.f/prnext@0.1.21-alpha npx --no-install prnext check --production --json npx --no-install prnext build ``` Gardez les dépendances natives optionnelles et alignez leurs versions sur celle du framework. React, React DOM et react-server-dom-webpack restent alignés sur 19.3.1 ; les plages Node prises en charge sont ^22.23.4, ^24.22.1 ou >=26.12.1. Reconstruisez chaque application activée avec son nouveau runtime avant de redémarrer le superviseur voulu. La nouvelle CLI refuse l’ancien protocole incompatible au lieu de reprendre silencieusement le contrôle. PRNext reste une alpha avec une compatibilité Next.js partielle. Un pilote applicatif représentatif et ses objectifs propres de fiabilité restent à qualifier. Vérifiez connexion, changement de compte, navigation, formulaires, streaming, panne de dépendance et rollback sur votre produit. Mettre à jour le framework npm ne déploie ni PRNext Host ni un service externe, et un rollback de code n’annule pas les écritures de base de données. ## Références techniques Les sept paquets de la 0.1.21-alpha sont disponibles sur npm. Les sources et le comparatif contrôlé ci-dessous détaillent les changements, leurs conditions et les limites des mesures. [PRNext 0.1.21-alpha sur npm](https://www.npmjs.com/package/@thomas.f/prnext/v/0.1.21-alpha) [Changements et implémentation du framework](https://github.com/Lorkydey/PRNext/pull/59) [Durcissement des proxys, images et RPC local](https://github.com/Lorkydey/PRNext/pull/56) [Navigation, Fast Refresh et notes de mise à niveau](https://github.com/Lorkydey/PRNext/pull/60) [Fiabilité des navigations et de Fast Refresh](https://github.com/Lorkydey/PRNext/pull/61) [Source du framework publié 7c15132a](https://github.com/Lorkydey/PRNext/commit/7c15132ade6da37c8a858873d405b33b4e566874) [Comparatif contrôlé avec la 0.1.20](https://github.com/Lorkydey/PRNext/actions/runs/42340893273) Publié: 2026-11-07 Modifié: 2026-11-07 Auteur: PRNext --- Langue: fr Canonical: https://prnext.dev/fr/blog/prnext-0-1-21-flight-cache-compilation Index: https://prnext.dev/llms.txt