Gerindo ambientes no Nuxt

Um dos desafios para desenvolvimento de aplicações no Nuxt é a falta de uma documentação clara acerca dos ambientes de desenvolvimento. Senti isto pois não tinha uma base forte de node.js (que ainda é uma das minhas maiores deficiências na minha formação enquanto desenvolvedor).

O desafio torna-se maior quando o ambiente de desenvolvimento é compartilhado em inúmeras máquinas, onde se faz necessário testes de carga, garantias de segurança e outros testes fundamentais para que a aplicação rode ágil, sem engasgos e performance. Posso falar do meu exemplo atual. Trabalho na a55 faz 1 mês, e neste período, meu chefe e eu entramos em acordo que os sites da Matriz brasileira e da filial mexicana poderiam usufruir-se de uma base de componentes únicas, considerando ter ambientes exclusivos para cada língua, hospedadas regionalmente, para melhor performance. Poderíamos entrar no mérito de instalarmos o módulo nuxt/i18n, mas isto fica para outro dia. O foco da conversa é ressaltar que temos muitos ambientes, com múltiplos endpoints e configurações únicas para cada lugar. Para tanto, criamos um esquema de branches do repositório que segue uma razoável organicidade:

• Branch dev – é onde que o desenvolvimento propriamente dito ocorre.
• Branch stage – subimos o projeto num link de stage, que irá fornecer um link único para que a equipe de qualidade possa fazer as devidas correções.
• Branch MX – nesta branch, quando realizado o commit, irá executar o processo de CD/CI e realizar a build para o site hospedado no servidor mexicano.
• Branch BR – faz o mesmo processo acima, só que hospedado no servidor nacional.
• Branch Main – ocupa papel fundamental como backup.

Optei por esta perspectiva pois imaginamos que a empresa vai expandir-se na América Latina, e possivelmente terá versão em inglês e francês.

A agulha no palheiro

Bom, desafio lançado! O foco agora é procurar sobre arquivos .env na documentação do Nuxt. Ao digitar os termos da pesquisa no Google, os principais materiais de ambientes de desenvolvimento apontavam para o artigo da Debbie O’Brien, uma das maiores evangelistas do Nuxt, explicando da necessidade de deixar de usar o dotenv e assumir o uso, dentro do nuxt.config.js, do publicRuntimeConfig e do privateRuntimeConfig.

Esta função possibilita inserir, dentro da lógica do Webpack, o controle de todos os dados de ambiente da sua aplicação Nuxt, porém não havia nenhum sinal do conteúdo que iria sanar minhas necessidades. Gastei dias e dias para encontrar uma solução razoável, considerando minhas brutais limitações em node.js, consegui encontrar a tão esperada solução, num dos confins de uma issue do github.

Bom, vamos compilar esta solução no meu package.json.

Em resumo:

• cross-env: é um pacote do npm que eu instalei em modo de desenvolvimento, que permite setar variáveis dentro do node. No caso, defini que o NODE_ENV se torne o nome da branch. Pessoalmente não sei se é uma boa prática de desenvolvimento, mas para a minha realidade, atende muito bem
• flag –dotenv: define qual arquivo de .env que iremos consultar dentro da plataforma. Como o Nuxt configura, por padrão, o dotenv-expanded, ele possibilitou passar de maneira simples e rápida qual arquivo .env que ele irá pegar. Por razões de segurança, não irei passar os valores de env aqui neste arquivo, mas imagine que são de rotas, de URL de tradução e de outros dados relevantes para o nuxt.config.js.

Nisto, basta executar o código desejado no terminal. Por exemplo:

• npm run dev:mx – este código irá importar os dados do servidor mexicano, e a tradução em es-mx.
• npm run generate:br – faz o processo de build do projeto considerando o arquivo de .env com os dados brasileiros.

Esta solução não está muito bem documentada, e espero que isto seja corrigido logo.