Symfony Reprise 1.0: Vite e Rsbuild ganham a cola que faltava no Symfony

PHP · "Loop"

O Symfony Reprise chegou à versão 1.0 com uma proposta fácil de confundir: ele não quer ser mais uma ferramenta de build. Vite e Rsbuild continuam responsáveis por empacotar JavaScript e CSS, gerar hashes, source maps e servir HMR. O Reprise cuida da cola entre esse resultado e uma aplicação Symfony.

Essa diferença importa porque o ecossistema já tem o Webpack Encore. A migração não é simplesmente trocar o nome de um pacote. É trocar o motor de frontend e manter uma integração familiar no PHP e no Twig.

O que a camada de integração entrega

O Reprise gera os arquivos entrypoints.json e manifest.json que descrevem os ativos produzidos. No lado do Symfony, o bundle lê esses dados e oferece helpers Twig para inserir scripts e folhas de estilo. A solução também cobre múltiplos builds, atributos nas tags, CDN, Subresource Integrity e integração com Symfony UX e Stimulus.

A instalação combina dependências dos dois mundos:

composer require symfony/reprise
npm install @symfony/reprise --save-dev

Em um projeto Vite, o plugin entra na configuração e recebe os pontos de entrada. A forma do bloco de build muda entre Vite 8 e versões anteriores, por isso vale seguir o exemplo correspondente na documentação em vez de copiar uma configuração antiga.

import { defineConfig } from 'vite';
import Symfony from '@symfony/reprise/vite';

export default defineConfig({
  plugins: [Symfony()],
  build: {
    rolldownOptions: {
      input: {
        app: './assets/app.js',
      },
    },
  },
});

No Twig, os helpers equivalentes inserem os arquivos ligados à entrada:

{{ reprise_entry_link_tags('app') }}
{{ reprise_entry_script_tags('app') }}

Por que o 1.0 muda a conversa

Até agora, o próprio projeto carregava um aviso de experimental. A versão 1.0 remove esse rótulo, passa a seguir versionamento semântico e assume a promessa de compatibilidade do Symfony. Isso não transforma software jovem em infraestrutura antiga, mas dá uma base mais clara para avaliar adoção.

O anúncio também cita testes de ponta a ponta com Vitest e Playwright, correções relacionadas a SRI e a possibilidade de desativar nomes de arquivo estáveis. A documentação inclui um mapa de migração que relaciona funções do Encore aos equivalentes do Reprise, algo mais útil do que uma lista genérica de vantagens.

Quem ganha mais com a troca

Projetos novos que já escolheriam Vite ou Rsbuild têm o caminho mais simples. O Reprise evita construir manualmente leitura de manifesto, resolução de URLs, tags Twig e tratamento do servidor de desenvolvimento. Também pode interessar a aplicações Symfony que querem sair do Webpack por razões concretas: tempo de build, familiaridade do time ou padronização com outros frontends.

Uma aplicação estável no Encore não precisa migrar só porque apareceu um 1.0. O Encore continua resolvendo o problema e a troca mexe em plugins, loaders, aliases, tratamento de CSS, cópia de arquivos e comportamento do ambiente de desenvolvimento. Quanto mais customizado o Webpack, menos “mecânica” será a migração.

Um roteiro sem salto de fé

  • liste entradas, assets copiados, plugins e loaders usados hoje;
  • monte um build paralelo com uma entrada pouco crítica;
  • compare HTML gerado, hashes, preload, SRI e URLs de CDN;
  • teste HMR, produção e deploy sem depender do cache local;
  • meça o ganho real antes de converter todas as entradas.

O mérito do Reprise é manter pequena a parte específica do Symfony. Se a equipe quiser trocar Vite por Rsbuild mais adiante, a integração do backend permanece reconhecível. É uma cola assumidamente fina — e, para infraestrutura de build, isso costuma ser uma qualidade.

Fontes