Após algumas conversas no grupo do Quasar Brasil no Telegram e algumas pesquisas pela internet, notei que não há um tutorial ou dica de como criar builds com o Quasar Framework para mais de 2 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 2 ambientes(desenvolvimento e produção) ?
Resolvendo o problema de muitas Builds
Por muito tempo eu tive esse problema, e analisei diversos tutoriais, 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 é windows, então eu necessito fazer algumas configurações extras para funcionar corretamente.
Estarei criando um projeto com o Quasar-cli, caso você não tenha conhecimento ainda, aconselho que assista as vídeo aulas 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 iremos modificar 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 bastei 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 travé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
Desta maneira, você pode criar suas builds para quantos ambientes quiser, sem a necessidade de instalação de pacotes externos na sua aplicação.
