E lá vamos nós com mais um artigo sobre JavaScript, o primeiro sobre o Next.js. Ainda não tenho tanto contato com ele, mas já temos um primeiro projeto na Wooza utilizando. Um dos pontos que precisávamos era de variáveis de ambiente no Next.js para funcionar nos nossos diversos (não me diga, Dulça?). Environments são fáceis de configurar no Next.js, porém, no nosso caso precisávamos de um algo mais. Veremos o que é...
\nSimples, basta criar os seguintes arquivos:
\nE dentro deles você coloca as variáveis, por exemplo:
\nAPI_URL=https://fodasse.com\nDEFAULT_SCROWBLES=VALORClaro, esses valores podem ou devem ser diferentes para cada um deles.
\nEssas variáveis funcionam de boa localmente, durante o desenvolvimento e tudo mais. Porém, na hora do build, por exemplo, podem rolar problemas.
\nNo caso do projeto da empresa nós usamos essas variáveis num service de captura de dados de uma API. No start do projeto, usando o next dev ou next start, ele pega corretamente as informações dos arquivos de environment, o primeiro de homologação e o segundo de produção.
O problema era na hora do Build do Next.js. Trabalhando com a parte de arquivos estáticos e geração de todas as págins nós não teríamos problema, porque no tempo de Build ele pega as informações que estão nos arquivos de environment. Mas na hora do acesso do usuário o service pega os dados de produção, que são os dados padrões. Isso porque as variáveis de ambientes só são acessadas no tempo de build, se perdem quando sobe pro servidor, S3 e afins.
\nCom isso, precisamos criar um arquivo JS com essas configurações pro nosso service acessar de qualquer lugar.
\nTemos três ambientes:
\nComo o next build pega por padrão as variáveis de ambiente de Produção, no CI/CD de Homologação acaba pegando as informações erradas, o que não queremos. Por isso eu precisava resolver isso, certo?
Simples. Precisamos instalar dois pacotes:
\nyarn add -D dotenv cross-envClaro, se usar o npm você executa o comando npm install --save-dev dotenv cross-env. Depois disso você precisa adicionar ou alterar as tasks de build nos scripts do seu packaeg.json:
{\n \"name\": \"seu-pacote\",\n \"scripts\": {\n \"build:hmg\": \"npm run clear && npm run env:hmg next build && next export\",\n \"build:prod\": \"npm run clear && npm run env:prod next build && next export\",\n \"env:hmg\": \"cross-env ACTIVE_ENV=development\",\n \"env:prod\": \"cross-env ACTIVE_ENV=production\",\n \"start\": \"npm run env:hmg next dev\",\n \"start:prod\": \"npm run env:prod next start\"\n }\n}Percebam que existem duas tasks de env: uma de hmg e outra para prod. Elas executam o cross-env, passando seus respectivos valores. Eu preferi usar development como valor para homologação por ser o valor default de desenvolvimento do Next.js, mas pode nomear como quiser.
Percebam que só coloquei duas tasks, de hmg e prod, isso porque nesse projeto nós usamos o ambiente de HMG para o desenvolvimento local. Mas você, e deve, colocar as informações de desenvolvimento local apontando para o ambiente de DEV.
\nDepois é só criar os dois arquivos de variáveis de ambiente, um com os dados de homologação chamado .env.development (ou com o sufixo que quiser):
API_URL=https://hmg-fodasse.com\nDEFAULT_SCROWBLES=VALOR_HMGE outro com os dados de produção chamado .env.production:
API_URL=https://fodasse.com\nDEFAULT_SCROWBLES=VALORPercebam que a URL é diferente, assim como a propriedade que inventei em cada um dos arquivos.
\nLembrando que no local você coloca as informações que precisar, caso tenha um ambiente de desenvolvimento apartado.
\nE depois disso você precisa criar um Builder que gere um arquivo que será usado pelos services. Eu o batizei de environment-builder.js. Vamos a ele:
const fs = require('fs');\nconst activeEnv = process.env.ACTIVE_ENV || 'development';\n\nconst env = require('dotenv').config({\n path: `.env.${activeEnv}`,\n});\n\nconst createEnvFile = () => {\n return new Promise((resolve, reject) => {\n fs.writeFile('environment.js', `export default ${JSON.stringify(env.parsed)}`, 'utf8', (error) => {\n return error ? reject(error) : resolve();\n });\n });\n};\n\nmodule.exports = createEnvFile;Nesse arquivo nós vimos que ele usa o dotenv para fazer a configuração baseado nos arquivos que foram criados, .env.development e .env.production.
E veja também que nas primeiras linhas ele pega o process.env.ACTIVE_ENV, que foi setado no package.json. Caso ele não exista, entra o padrão development. E depois uma variável env é criada com o config do dotenv.
Com isso, todas as variáveis que estão nos arquivos de environment são atribuídos a um objeto parseado pelo dotenv de acordo com o ACTIVE_ENV passado. Veja que na Promise a gente coloca um JSON.stringify com o nó parsed.
Um método createEnvFile é criado e exportado para ser executado em algum local que veremos logo, logo.
Ele cria um arquivo chamado environment.js, e é nesse arquivo que os services e afins vão se basear. Abaixo segue como o arquivo fica quando gerado:
export default {\n 'API_URL': 'https://fodasse.com',\n 'DEFAULT_SCROWBLES': 'VALOR',\n};Porém, você precisa colocar esse arquivo no .gitignore, pois esse arquivo será gerado a cada start e build, já que ele sofre alterações dependendo do ambiente.
Aí você acaba se perguntando \"Mas como que eu gero esse fodasse?\". E é bem tranquilo, só vai depender de como você tem o seu next-config.js. Caso não tenha nenhum plugin e afins, é só colocar a execução do createEnvFile() no module.exports:
const createEnvFile = require('./environment-builder');\n\nmodule.exports = createEnvFile();Mas pode ser que você já use plugins, como o next-images, aí precisa adicionar dentro da configuração dele, passando o webpack, executando o método createEnvFile() e retornando as configurações:
const withImages = require('next-images');\nconst createEnvFile = require('./environment-builder');\n\nmodule.exports = withImages({\n webpack: (config) => {\n createEnvFile();\n return config;\n },\n});Agora que temos o arquivo environment.js gerado, use à vontade. Veja um exemplo numa service fodasse:
import env from '../../environment';\n\nexport const fetchData = async () => {\n const url = `${env.API_URL}/${env.DEFAULT_SCROWBLES}`;\n const result = await fetch(url).then((items) => items.json());\n const dataResult = result.data;\n\n return { dataResult };\n};Claro, é um exemplo completamente fodasse, você faz o que quiser, manipulações, Builders, tratamento de erros e afins, mas só quis mostrar que agora você pode importar o objeto exportado no arquivo environment.js.
Espero que tenha ajudado vocês aí, que tenham conseguido entender o propósito do artigo, os motivos e porquês. Depois dessas alterações nós alteramos o Build da Pipeline de Homologação, adicionando a task de homologação build:hmg.
Ficou alguma dúvida? Mandem nos comentários. Precisa de melhorias? Mandem brasa nos comentários também, tamo junto ;)
\nBeijo na alcatra.
\n[EDITED]
\nAtualizei o código do Builder, dando uma simplificada. Valeu, Filipe ;)
\n[/EDITED]
"}},"pageContext":{"nextPost":{"fields":{"slug":"/como-criar-testes-em-listeners-no-react-testing-library/"},"frontmatter":{"title":"Como criar testes em listeners no React Testing Library"}},"previousPost":{"fields":{"slug":"/o-que-e-e-como-resolver-o-content-security-policy/"},"frontmatter":{"title":"O que é e como resolver o Content Security Policy"}},"slug":"/como-criar-variaveis-de-ambiente-no-nextjs/"}},"staticQueryHashes":["1271460761","2963127411","3623170217","764694655"]}