# PRNext 0.1.18 : navigation avec état conservé et production renforcée PRNext 0.1.18-alpha améliore ce qui se passe entre deux pages, entre deux compilations et entre deux déploiements. Vous pouvez retrouver une page avec son formulaire intact, donner la priorité à une navigation réelle et réutiliser davantage de travail de compilation. Côté serveur, les caches partagés et les limites de ressources permettent de mieux contrôler le travail lancé pour chaque requête. Cette version ajoute aussi une commande de création de projet, la prise en charge du compilateur TypeScript 7 installé dans l’application et une intégration facultative du React Compiler officiel. Voici les changements par usage, puis le journal des modifications et les vérifications à effectuer dans votre application. ## Commencer avec un projet prêt à lancer La commande prnext create prépare une application App Router minimale avec ses fichiers, ses scripts de développement et sa configuration. TypeScript est choisi par défaut ; l’option --js crée un projet JavaScript. Vous disposez ainsi d’un point de départ cohérent pour développer, compiler et lancer l’application. La création accepte uniquement un dossier absent ou entièrement vide. Elle refuse de remplacer un projet existant. L’option --no-install écrit les fichiers sans installer de dépendances ni accéder au réseau, notamment pour intégrer le projet dans un workspace avec son propre gestionnaire de paquets. ```sh npx @thomas.f/prnext create my-app cd my-app npm run dev ``` Ces commandes nécessitent PRNext 0.1.18-alpha ou une version ultérieure. ## Retrouver une page sans recommencer son travail Dans l’App Router, PRNext conserve des branches inactives avec React Activity. Lorsque vous revenez sur une destination autorisée sous le même layout monté, ses composants peuvent retrouver leur état : un filtre sélectionné, un formulaire commencé ou un panneau ouvert. Les effets sont arrêtés pendant que la branche est masquée. La limite par défaut est de quatre branches inactives pendant deux minutes, avec un budget partagé entre les layouts concernés. Il s’agit d’une limite en nombre d’entrées et en durée, pas d’une garantie de consommation RAM. La configuration navigationCache permet d’ajuster cette conservation ou de la désactiver. Cet état reste soumis à la fraîcheur des données et aux droits d’accès. Les Server Actions, router.refresh() et les changements d’identité observés invalident les branches inactives. Une navigation arrière ou avant demande une réponse Flight fraîche avant de révéler une destination conservée. Après une authentification personnalisée, l’application doit déclencher le rafraîchissement approprié. Un rechargement complet ne conserve pas les brouillons en mémoire. ## Donner la priorité au clic et mieux traverser une coupure réseau Les préchargements issus du survol, du focus clavier et du toucher passent avant les scans de liens visibles. Une navigation réellement demandée reste prioritaire. Les files et le nombre de préchargements simultanés sont bornés ; l’économiseur de données, les connexions lentes et les onglets masqués limitent le travail spéculatif. Avec prefetch={false}, un lien ne déclenche pas non plus de préchargement au survol ou au focus. Lorsqu’une requête GET de navigation App échoue à cause du transport, PRNext peut la reprendre dans un budget de trente secondes et avec trois tentatives au maximum. La page actuelle et son état restent visibles pendant cette récupération. Une nouvelle navigation annule l’ancienne, et la reconnexion repart avec les cookies actuels plutôt qu’avec une réponse privée enregistrée. Cette récupération ne rejoue jamais automatiquement une Server Action ou un autre POST. Une mutation peut avoir été exécutée même si sa réponse a été perdue. L’application conserve la responsabilité de vérifier son résultat avant de proposer une nouvelle action. Il ne s’agit pas d’un mode hors ligne persistant ; le hook facultatif useOffline permet d’afficher son propre indicateur de connexion. ## Transmettre les changements Flight avec un repli complet Les navigations App peuvent négocier un transport Flight différentiel en streaming. Quand le navigateur possède une base réutilisable, PRNext lui transmet les différences nécessaires pour reconstruire exactement la nouvelle réponse. Les bases sont bornées et liées au déploiement ainsi qu’au contexte d’authentification. Une base absente, expirée ou incompatible entraîne une réponse Flight complète. Un delta invalide permet une unique nouvelle tentative sans delta pour cette navigation GET. Les actions ne sont pas rejouées. L’objectif est de réduire les octets répétés lorsque le contenu s’y prête, sans rendre la navigation dépendante de la présence d’un cache. Les buffers et les bases retenues disposent de limites explicites. Le traitement du HTML et des flux évite aussi des copies binaires agrégées inutiles. Un trajet serveur reste cependant composé du rendu React, du code applicatif et de ses accès aux données ; le transport différentiel ne promet pas un gain identique sur toutes les pages. ## Activer React Compiler et comprendre ce qu’il optimise L’option reactCompiler active le React Compiler officiel embarqué. Elle reste désactivée par défaut. Le traitement vise les composants navigateur de l’application et le rendu serveur isolé des Client Components App, en développement et en production. Les Server Components, les modules de Server Actions, les dépendances npm et le graphe serveur Pages restent hors de ce traitement. Vous pouvez adopter le compilateur progressivement avec compilationMode: annotation et la directive use memo. La directive use no memo exclut une fonction. Le rapport prnext compiler indique les fonctions observées, celles optimisées ou ignorées et les raisons fournies par le compilateur. Il distingue aussi les transformations réutilisées depuis le cache. Ce rapport décrit des décisions de compilation, pas une mesure de rapidité de l’interface. Les graphes JavaScript éligibles sont enregistrés sous forme de métadonnées binaires et de blocs adressés par leur contenu. Les sommes de contrôle sont vérifiées ; une entrée absente, corrompue ou supprimée en parallèle devient un cache manqué et se recompile. En production, les noms locaux des CSS Modules et des animations peuvent être raccourcis, les exports internes compactés et les chunks partagés réutilisés, en préservant les interfaces publiques. ## Utiliser le TypeScript installé dans votre application PRNext prend en charge TypeScript 7 par son exécutable natif officiel, lorsqu’il est installé dans le projet avec ses dépendances de plateforme. Les vérifications de production, prnext typecheck et les diagnostics de développement utilisent ce compilateur. PRNext ne télécharge pas un compilateur pendant le build. TypeScript 5 et 6 conservent leur intégration par l’API du compilateur. Les contrôles ne produisent pas de JavaScript et gardent leur état incrémental dans un dossier temporaire dédié. Les nouveaux fichiers et les changements de configuration relancent la génération de surveillance correspondante. La génération des routes typées fonctionne aussi avec TypeScript natif et préserve les commentaires JSONC lors des ajustements de configuration. Les changements de langage ou de configuration de TypeScript 7 restent à vérifier dans chaque projet. ## Partager les caches entre plusieurs processus Un cache local ne suffit pas lorsqu’une application utilise plusieurs workers ou plusieurs instances. PRNext ajoute des adaptateurs Redis facultatifs pour partager les résultats éligibles. Le gestionnaire Cache Components prend en charge les résultats use cache. createRedisIncrementalCache couvre séparément le HTML natif et l’ISR, fetch et unstable_cache. Ces rôles sont explicites : activer un adaptateur ne remplace pas automatiquement tous les caches. Redis reste une dépendance facultative de l’application ; un projet classique et un projet créé par la commande de démarrage n’en ont pas besoin. Les régénérations partagées utilisent des baux pour coordonner le travail et empêcher un ancien producteur de republier un résultat après invalidation ou expiration. Les tags et les valeurs binaires sont conservés dans ce modèle. Le résultat recherché est une coordination cohérente entre processus, avec les mêmes règles d’éligibilité et d’isolation des données que dans l’application. ## Mieux gérer les onglets ouverts pendant un déploiement Chaque artefact de production possède une identité de déploiement. PRNext peut conserver des assets immuables de générations précédentes dans des limites de durée, de nombre de générations et de taille. Un onglet déjà ouvert peut ainsi terminer le chargement des ressources correspondant à son code, au lieu de recevoir arbitrairement celles du déploiement suivant. Cette conservation concerne les assets éligibles. Elle ne justifie pas de servir une ancienne réponse personnalisée ou de rejouer une action. Le proxy et les caches placés devant PRNext doivent préserver les en-têtes et les variations nécessaires au protocole de déploiement. L’option htmlOnly permet également de sélectionner des pages App entièrement statiques et non interactives. Leur HTML de production conserve les styles, les polices et les métadonnées, sans scripts de démarrage ni payload Flight. Les Client Components, les Server Actions, les liens interactifs et les fonctions de rendu incompatibles sont refusés pour ces routes. Une entrée dans ces pages réalise une navigation de document classique. Le mode est explicite et ne retire pas le JavaScript des autres pages. ## Borner le travail et laisser les requêtes se terminer Le moteur renforce l’admission des requêtes, les files d’attente et les budgets de réponses pour éviter qu’une charge importante crée du travail sans limite. La répartition tient compte des routes et laisse de la place aux requêtes qui ne font pas partie du flux le plus chargé. Les profils de fonctionnement tiennent mieux compte des plafonds CPU et mémoire visibles dans l’environnement. Les workers peuvent être arrêtés ou remplacés sans confondre la fin du flux HTTP avec la fin du travail associé. Les finalisations de cache et les tâches suivies après réponse sont prises en compte pendant le drainage. Les processus bloqués conservent une borne d’arrêt, et les reprises de workers ne rejouent pas une requête susceptible d’avoir déjà modifié des données. La mise en veille des workers inactifs peut réduire les ressources gardées entre deux périodes d’activité, avec un coût de réveil lors de la prochaine demande. Le processus natif et les autres services restent présents. Ce mécanisme du moteur est distinct de la mise en veille d’une application complète chez un hébergeur. Les gains dépendent du trafic et du projet ; cette version ne promet pas une réduction générale de RAM. ## Observer le code réellement exécuté et chargé Les hooks instrumentation permettent d’enregistrer l’instrumentation et de suivre les erreurs de requête dans les environnements Node, RSC et Edge pris en charge. L’export OTLP HTTP JSON facultatif relie les étapes HTTP natives, Node, RSC et fetch au contexte OpenTelemetry de l’application. Les files d’export sont bornées et une panne de télémétrie ne change pas la réponse applicative. L’analyse du JavaScript initial inclut les imports attendus pendant l’hydratation et les chunks dynamiques réellement utilisés par le rendu serveur. Les rapports distinguent les chemins échantillonnés, les tailles selon la compression et les couvertures incomplètes. Les styles sont mieux rattachés aux routes concernées. Vous pouvez ainsi examiner ce que charge une page donnée sans confondre le total de tous les assets du projet avec sa charge initiale. ## Changelog de la 0.1.18 La navigation réunit la conservation bornée des branches App, la reprise des GET après une coupure réseau, la priorité donnée aux interactions et le transport Flight différentiel. Les étapes de navigation et de préchargement restent facultatives : navigation(), prefetch() et ensureStatic permettent de définir les phases éligibles avec Cache Components, sans rendre les contenus privés réutilisables pour un autre utilisateur. La compilation ajoute React Compiler, son rapport de décisions, TypeScript 7 natif et le stockage binaire des graphes éligibles. Les builds raccourcissent les identifiants CSS locaux et réutilisent les chunks partagés. La compilation à la demande sait matérialiser les destinations après middleware et réécritures, conserver les branches parallèles nécessaires et laisser les routes sans rapport encore froides. La production gagne les adaptateurs Redis, l’identité de déploiement, la conservation bornée d’assets et les routes htmlOnly. Le pré-rendu parallèle et ses finalisations sont mieux coordonnés. L’admission, les files, les buffers de réponse et le cycle de vie des workers disposent de contrôles renforcés. Le rendu Web reste le choix par défaut ; le chemin Node facultatif sert à comparer les comportements sur un même projet. Les correctifs de fiabilité couvrent notamment la découverte de sous-dossiers après des notifications de fichiers regroupées, la résolution des helpers de métadonnées et le rafraîchissement des diagnostics TypeScript natifs. Les tests de navigation attendent une vraie page interactive, et les tests de workers distinguent un démarrage valide un peu plus lent d’un dépassement des bornes d’arrêt. Le nouveau générateur prépare les scripts et les fichiers d’une application App Router minimale. ## Validation et adoption dans votre projet Cet article documente le code source 05a9ccd. La validation complète passe sur Linux, macOS et Windows et couvre le moteur Rust, les tests unitaires, les types, les intégrations et les navigateurs. Les archives des six plateformes sont construites à partir de ce même commit. Douze installations isolées vérifient les deux dispositions de dépendances, et dix-huit scénarios de cycle de vie couvrent Node.js 22, 24 et 26. La compatibilité Next.js reste partielle et cette version reste une alpha. Vérifiez vos routes, vos accès aux données, vos formulaires et vos Server Actions, puis compilez et lancez l’application en production. Adoptez séparément les options React Compiler, Redis, navigation par étapes et htmlOnly pour pouvoir observer leur effet dans votre projet. Après une mise à jour du paquet, recompilez et redémarrez votre application. Utilisez les guides fournis avec la version installée pour retrouver les options réellement disponibles. Les résultats de performance associés à un autre instantané du code ne constituent pas un nouveau benchmark de ce commit. Mesurez le CPU, la RAM et le temps de réveil sur votre application avant de généraliser un gain. ## Sources [PRNext : changements depuis v0.1.17-alpha / Changes since v0.1.17-alpha](https://github.com/Lorkydey/PRNext/compare/v0.1.17-alpha...05a9ccd20e86a20698b4a37bdf6a6baa3411ceaf) [Changelog du code documenté / Changelog for the documented source](https://github.com/Lorkydey/PRNext/blob/05a9ccd20e86a20698b4a37bdf6a6baa3411ceaf/CHANGELOG.md) [Guides de compatibilité / Compatibility guides](https://github.com/Lorkydey/PRNext/blob/05a9ccd20e86a20698b4a37bdf6a6baa3411ceaf/packages/prnext/docs/ai/compatibility.md) [Validation multiplateforme / Cross-platform validation](https://github.com/Lorkydey/PRNext/actions/runs/40980719114) Published: 2026-10-30 Modified: 2026-10-30 Author: PRNext --- Language: fr Canonical: https://prnext.dev/fr/blog/prnext-0-1-18-navigation-compilation-production Index: https://prnext.dev/llms.txt