PRNext 0.1.21: menos trabalho no Flight e nos builds

#Preparar todos os processos antes da primeira resposta dinâmica

A opção explícita --prewarm prepara cada processo de renderização e repete essa preparação do framework nos substitutos e nos despertares após inatividade. No máximo duas preparações executam juntas no orçamento inicial de 15 segundos. Um pequeno modelo RSC e HTML interno exercita o renderer oficial sem importar rotas da aplicação nem ler dados de contas.

A prontidão inicial aguarda essa preparação. Imports da aplicação, conexões de banco e dados da requisição ainda podem adicionar trabalho à primeira renderização real. Um substituto posterior que não conclui a preparação registra um diagnóstico e mantém o carregamento sob demanda para requisições normais. Esse carregamento continua sendo o padrão, sem repetir requisições que falharam. Meça a inicialização junto com a primeira resposta dinâmica, em vez de considerar um arquivo estático disponível como prova de que o React está preparado.

npx --no-install prnext start --workers 2 --prewarm

#Fazer menos alocações em torno da mesma resposta Flight

Os envelopes de transporte Flight e suas listas de transferência são reutilizados apenas dentro da própria resposta e liberam as referências aos buffers após a transferência. Scripts inline de inicialização grandes são codificados diretamente em buffers limitados. Outras estruturas só são criadas quando necessárias, e fragmentos HTML comuns completos seguem um caminho direto.

O conteúdo codificado, o base64 e o nonce CSP preservam seu significado. Cancelamento, créditos de leitura, cópias defensivas de dados de produtores externos e isolamento entre respostas continuam presentes. Atributos entre aspas e HTML ambíguo mantêm o parser. Reduzir esse trabalho não permite guardar uma resposta privada para outra requisição.

#Observar o tamanho do Flight e o progresso do renderer

A inspeção opcional agrupa bytes, chunks e resultados do Flight por padrão de rota e fase de renderização. Ela distingue amostras concluídas, canceladas, com falha e expiradas, e informa quando modelo e shell ficam prontos se esses marcos forem observados. RSC e SSR podem observar o mesmo conteúdo: seus tamanhos e contagens de requisições não devem ser somados.

As durações incluem trabalho da aplicação e esperas assíncronas, não apenas CPU do codificador ou decodificador. Amostras ausentes não viram zero. Os diagnósticos excluem corpos, cookies, valores de autorização e consultas brutas. Métricas opcionais de GC, heap e loop de eventos oferecem outra visão, sem observador de GC quando desativadas. Os padrões V8 e as opções explícitas do operador permanecem iguais.

npx --no-install prnext start . --inspect
npx --no-install prnext inspect --json

#Reutilizar metadados sem retirar as verificações

Builds repetidos podem reutilizar resumos Oxc tipados e limitados com as diretivas e exportações usadas nas próximas etapas. Esses resumos imutáveis não retêm texto-fonte, AST ou closures da aplicação. As verificações de identidade e geração continuam confirmando se cada registro corresponde à entrada atual. Uma entrada ausente ou inválida leva de volta ao trabalho normal.

A descoberta de dependências nativas também reutiliza provas de escopo limitado quando o grafo é comprovadamente livre de código nativo. Efeitos desconhecidos, hooks personalizados e entradas alteradas mantêm seus controles; um grafo opaco não é reutilizado às cegas. Aplicações e ferramentas de referência também recebem atualizações selecionadas, incluindo as bases Next 16.4.4, Better Auth 1.7.15 e o cliente Redis 6.3.1.

#Limitar as cópias e entender as fases do build

As cópias do rastreamento standalone e do runtime usam concorrência limitada, tratamento determinístico de aliases e orçamentos de admissão. Alterações na origem durante a cópia continuam detectáveis. Se uma operação falhar, as escritas já iniciadas terminam antes de descartar a área temporária; o último build publicado é preservado. Chunks do servidor Pages e seus source maps são reescritos em memória antes da primeira gravação.

build --timings expõe as fases React para separar uma etapa lenta do compilador do trabalho com arquivos. O total exclui a inicialização dos módulos da CLI, e fases aninhadas se sobrepõem, por isso não se deve somar todas as durações. Os relatórios ficam fora dos manifestos de implantação e dos assets do navegador.

npx --no-install prnext build --timings

#Manter o React no controle do cache e da continuação PPR

Um callback em cache continua entrando uma vez no renderer oficial do React, incluindo seu contexto React.cache. Resultados primitivos elegíveis usam um formato privado compacto e versionado. Objetos, nós React, funções e referências temporárias mantêm o Flight canônico, com os bytes originais para resultados complexos comuns. Strings com BOM, UTF-16 malformado ou valores próximos do limite de renderização também mantêm o tratamento oficial.

Escopos privados por requisição, tags, TTLs e novos objetos decodificados são preservados. Muda o codec de resultado, não surge um cache entre contas. No PPR nativo, o parsing imutável e limitado e os dados de prefixo só podem ser reutilizados depois de verificar novamente os bytes e o SHA do artefato atual. Continuações mutáveis são clonadas por requisição. Continuações aninhadas ou não diretas mantêm a normalização existente quando necessária.

As entradas RSC também usam um novo espaço de chaves. Após atualizar, os resultados antigos não são reutilizados: as primeiras chamadas preenchem novamente os caches elegíveis, um custo a considerar ao observar o aquecimento.

#Retirar da fila as solicitações abandonadas

Uma requisição de desenvolvimento cancelada ou expirada não mantém viva sua demanda de compilação na fila. Uma compilação compartilhada ainda necessária para outro solicitante conserva seu próprio ciclo de vida. Isso evita trabalhar apenas para uma requisição desconectada sem cancelar trabalho útil para outra aba.

As notificações RPC de desenvolvimento continuam sendo a referência após sua primeira publicação aceita. Um snapshot de arquivo atrasado não pode restaurar um diagnóstico já apagado por RPC. As notificações apenas por arquivo seguem disponíveis até estabelecer RPC, sem misturar gerações antigas.

No desenvolvimento, as navegações sucessivas e o Fast Refresh também coordenam seus fluxos Flight. Uma resposta ainda em andamento pode dar lugar à próxima rota sem restaurar uma árvore antiga de componentes e perder o estado do layout compartilhado. A mudança se limita aos GETs de navegação em desenvolvimento, sem repetir mutações; as respostas de produção e as Server Actions mantêm a decodificação estrita. Com navigationCache.authCookies configurado para os cookies de sessão, a reautorização continua prioritária: os rascunhos de um usuário não são reutilizados por outro.

Uma Server Action também pode substituir a visualização enquanto uma atualização já aplicada está sendo confirmada. O Fast Refresh agora distingue essa troca de visualização do cancelamento da atualização. Erros reais, cancelamentos e prazos de rede continuam sendo falhas, sem reenviar a Action.

Essa integração de desenvolvimento permanece vinculada à versão do React validada com o PRNext. Ela usa uma opção experimental do cliente Flight sem ativar esse comportamento em produção.

#Validar o Node 26 com os mesmos artefatos

A CI Linux acrescenta verificações com Node 26 para runtime e HTTP, Chromium, o consumidor SaaS e as instalações do pacote, com layouts hoisted e aninhados. Essa cobertura de navegador é Chromium. Ela não substitui a matriz principal Linux, macOS e Windows nem escolhe o runtime Node de um ambiente de implantação.

Cobertura funcional não fornece um número de desempenho para Node 26. Compare uma mudança de runtime com os mesmos artefatos e dependências e valide seus próprios fluxos. Nenhum ganho numérico de Node 26 é atribuído a esta campanha, executada no Node 22.23.4.

#Ler cada medição dentro do seu escopo

A comparação controlada do código publicado de 0.1.20 com o candidato 7c15132a é executada em Linux x64 e Node 22.23.4. São doze pares por rota e 72 janelas no total, com dois workers, limites visíveis de duas CPUs e 5 GiB e afinidade com essas duas CPUs. Cada janela dura quinze segundos após dois de aquecimento, com oito conexões SSR, duas para a API JSON e oito para streaming.

Foram concluídas 774.665 respostas úteis dentro das janelas e 775.089 incluindo a drenagem. As 424 concluídas durante a drenagem não entram no cálculo da vazão. Os contadores de erros HTTP, transporte e validação são zero. O aquecimento é contado separadamente: 51.123 respostas dentro de suas janelas e 51.552 com a drenagem.

As medianas das razões pareadas candidato/referência são 0,9944 para vazão SSR, 0,9941 para a API JSON e 0,9978 para streaming. As razões de p95 correspondentes são 1,0361, 1,0056 e 1,0028. Todos os intervalos pareados relatados incluem 1. Os orçamentos fixados antes da medição, queda de vazão de no máximo 10% e aumento do p95 de no máximo 15%, foram atendidos. Esses resultados próximos da referência não demonstram uma aceleração geral.

O arquivo JavaScript de referência corresponde exatamente ao publicado para 0.1.20, e o do candidato à validação Linux desse código. Entretanto, os dois executáveis nativos foram reconstruídos separadamente e não são os bytes exatos do nativo público histórico nem do nativo validado para a release. O resultado compara essas composições associadas ao código sem isolar as mudanças JavaScript.

As observações do kernel e dos processos foram verificadas para todas as 72 amostras. A memória continua sendo amostrada, limites ancestrais ocultos por namespaces e contenção do runner ficam fora dessa verificação, e nem todas as dependências de build ou transitivas foram certificadas byte a byte. Essas três cargas sintéticas não estabelecem redução global de CPU ou RAM, capacidade de produção nem SLA.

#Definir a origem pública e os limites do controle local

A política salva de origem pública e proxies confiáveis passa a valer nas entradas de desenvolvimento, persistentes e nativas com várias aplicações, incluindo encaminhamento HTTP e WebSocket. O PRNext verifica o par que realmente se conecta antes de aceitar autoridade ou protocolo encaminhados. Uma origem canônica configurada tem prioridade; confiar em um proxy não certifica toda a cadeia de endereços IP do cliente.

As URLs alternativas de imagens são montadas por componentes, e sua origem normalizada final é verificada antes de permitir uma exceção de acesso interno. O RPC do compilador e do supervisor autentica as duas pontas e vincula nonces novos aos bytes exatos dos comandos e respostas. Mensagens e prazos continuam limitados. A mudança de protocolo torna necessário parar o supervisor antigo antes da atualização.

#Parar o supervisor antigo antes de substituir sua CLI

Se usar o supervisor persistente, inspecione-o e pare-o com a CLI antiga ainda instalada, no mesmo PRNEXT_PM_HOME, antes de substituir pacotes. pdown afeta o supervisor e todas as aplicações gerenciadas que compartilham esse diretório: planeje a manutenção em conjunto. Atualizar só a CLI global não substitui cada runtime. Guarde fontes, lockfile, configuração, build e backup compatível do banco para rollback.

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

Mantenha as dependências nativas opcionais e alinhe suas versões com o framework. React, React DOM e react-server-dom-webpack permanecem em 19.3.1; as faixas Node aceitas são ^22.23.4, ^24.22.1 ou >=26.12.1. Reconstrua cada aplicação habilitada com seu novo runtime antes de reiniciar o supervisor desejado. A nova CLI recusa o protocolo antigo incompatível em vez de assumir o controle silenciosamente.

O PRNext continua alpha, com compatibilidade parcial com Next.js. Um piloto representativo e seus objetivos de confiabilidade ainda precisam ser qualificados. Verifique login, troca de conta, navegação, formulários, streaming, falhas de dependências e rollback no seu produto. Atualizar o framework npm não implanta o PRNext Host nem serviços externos; rollback de código não desfaz gravações no banco.

#Referências técnicas

Os sete pacotes da versão 0.1.21-alpha estão disponíveis no npm. O código e a comparação controlada abaixo explicam as mudanças, suas condições e os limites das medições.

PRNext 0.1.21-alpha no npm

Mudanças e implementação do framework

Reforço de proxies, imagens e RPC local

Navegação, Fast Refresh e notas de atualização

Confiabilidade da navegação e do Fast Refresh

Código do framework publicado 7c15132a

Comparação controlada com a versão 0.1.20