Usamos cookies para medir audiência e melhorar sua experiência. Você pode aceitar ou recusar a qualquer momento. Veja sobre o iMasters.
Tenho percebido uma certa dor recorrente ao configurar variáveis de ambiente em múltiplos projetos que utilizam Vite. Embora o suporte nativo seja bom para cenários simples, rapidamente encontramos limitações.
Um problema clássico é a necessidade de ter diferentes configurações para diferentes ambientes (desenvolvimento, staging, produção) de forma granular, não apenas um .env.production.
Outro ponto é a segurança: expor chaves de API diretamente no frontend pode ser um risco, e o Vite, por padrão, expõe tudo que começa com VITE_. Precisamos de uma maneira mais controlada de expor apenas o estritamente necessário e talvez até mascarar ou transformar alguns valores.
A validação das variáveis também é um gargalo. Sem um schema claro, é fácil cometer erros que só aparecem em produção.
E vocês, como lidam com esses cenários? Já se depararam com desafios semelhantes e quais soluções adotaram? Estou pensando em criar um pequeno plugin para abstrair essas dificuldades, mas gostaria de ouvir a experiência da comunidade primeiro.
Isso parece bom para começar, mas eu queria comparar antes e depois. Principalmente em migração gradual, porque é ali que o custo aparece quando o time muda.
kkkk
💭
Essa pauta fica mais útil quando separa promessa de rotina. No papel segurança parece simples. na prática pesa em migração gradual
Para mim a pergunta prática é onde frontend/build entra no fluxo real. Sem esse recorte, fica fácil vender ganho e esquecer manutenção.
Se o time tivesse que medir uma coisa aqui, seria frontend/build ou migração gradual?
Quem fica responsável por performance quando o primeiro dev que puxou isso sair do projeto?
Eu levaria isso para um piloto bem limitado. Se frontend/build não melhorar sem piorar migração gradual, melhor parar cedo.
O que seria sinal de parar esse teste antes de virar padrão?