Após algumas conversas no grupo do Quasar Brasil no Telegram e algumas pesquisas na internet, notei que não há artigos ou dicas sobre como criar builds com o Quasar Framework para mais de dois ambientes.

Apesar de existir uma dica na documentação oficial, ela ficou um pouco escondida e pouco notada por nós, desenvolvedores.

Então decidi fazer este artigo para auxiliar quem tiver essa necessidade.

Parâmetro de contexto

Segundo a documentação do Quasar Framework, o quasar.conf.js exporta uma função que usa um ctx (parâmetro de contexto) e retorna um Object. Esse ctx permite que você mude dinamicamente seu website/configurações de aplicativo com base nesse contexto:

Ou seja, podemos configurar o env de nossa aplicação para o ambiente de desenvolvimento e ambiente de produção. Uma necessidade básica que quase todo projeto tem é a configuração da API ao qual irá se conectar. Uma boa prática é ter uma API para desenvolvimento, e outra para produção.

Configurando Variáveis Environment

Para que não tenhamos que modificar manualmente em nossa aplicação toda vez que formos gerar uma build para produção, nós usamos o ctx dentro do quasar.conf.js algumas variáveis environment:

Mas e quando precisarmos gerar builds para mais de dois ambientes (desenvolvimento e produção)?

Resolvendo o problema de muitas Builds

Por muito tempo eu tive esse problema, analisei diversos artigos, e achava a solução um pouco complexa, mas recentemente, analisando a documentação do Quasar, notei algo interessante.

Notei que podemos ir além e fornecer para a aplicação valores retirados de variáveis env desta forma:

Exemplo prático

Vou tentar mostrar como faço isso agora. Meu sistema operacional é o Windows, então preciso de algumas configurações extras para funcionar corretamente.

Criarei um projeto com o Quasar-cli. Caso não tenha conhecimento ainda, recomendo que assista as videoaulas do meu canal no Youtube para aprender.

Chamei o projeto de quasarenv.

O primeiro passo é configurar o nosso arquivo quasar.conf.js com a variável API:

No ambiente de desenvolvimento teremos a variável API como “http://dev.com.br”, mas observe que para o ambiente de produção a variável API dependerá da variável MY_API que iremos configurar posteriormente.

Para termos certeza disso modificaremos nossa page Index.vue:

Note que criamos apiAtual que recebe o process.env.API, e o resultado disso pode ser visto ao rodar nossa aplicação com o comando:

quasar dev

Ao inicializar nossa aplicação em modo de desenvolvimento, temos o resultado:

A nossa variável exibe a Url da api de desenvolvimento corretamente. Agora, digamos que temos um ambiente de homologação com uma API também para esse ambiente.

Para essa tarefa funcionar no sistema operacional Windows, instalei globalmente o pacote cross-env. Basicamente ele permite que você defina e use variáveis ambiente em seu terminal favorito (no Windows isso é um problema, mas esse pacote resolve isso).

Para instalar só precisei rodar o comando no terminal:

npm install -g cross-env

Precisamos agora configurar o nosso package.json com novos scripts:

O novo script adicionado foi build:homologa. Nele definimos a variável MY_API através do cross-env, e por fim rodamos a build com o comando quasar build.

Para executar esse script, basta você abrir seu terminal na pasta da sua aplicação e rodar o comando:

npm run build:homologa

Nossa build será gerada, e ao final teremos o diretório dist/spa-mat em nossa aplicação. Entramos nele através do terminal e iniciamos um servidor para simular um ambiente de produção através do comando:

quasar serve

O servidor é levantado na porta 4000:

No seu browser de preferência, acesse a url http://localhost:4000 e o resultado deverá ser:

Como nossa variável env API depende da variável MY_API que passamos através do terminal, ela foi mudada a partir do nosso script criado em nosso package.json.

Conclusão

Dessa forma você pode criar suas builds para quantos ambientes quiser, sem a necessidade de instalação de pacotes externos na sua aplicação.