Compartilhe este conteúdo:

O Angular 15 simplesmente não envia mais arquivos de ambiente por padrão.
Você ainda pode criá-los e configurar sua substituição com base no destino de construção, como era feito automaticamente na criação do projeto nas versões anteriores.

Um propósito mal compreendido

A origem da confusão que surgiu recentemente sobre a falta desses arquivos no novo projeto criado na ng-cliversão 15, tem suas raízes no equívoco de que src/environments/environment.ts e src/environments/environment.prod.ts eram algum tipo de caminho sagrado codificado nas entranhas mais profundas do framework Angular.
A realidade é que eles eram apenas uma escolha padrão de conveniência, sem referência na base de código, e que poderiam ter sido substituídos por caminhos e nomes diferentes sem prejudicar a aplicação.

Papel original

O único lugar no código onde você poderia encontrá-los referenciados na criação do projeto era main.ts, gerado com algo assim:

...
import { environment } from './environments/environment';

if (environment.production) {
  enableProdMode();
}
...

Sua environment.production propriedade foi usada para verificar se a compilação recém-iniciada precisava ser habilitada ProdMode ou não.
Esta função estava desativando um sinalizador (sim, o sinalizador é de fato isDevMode, e não isProdMode como se poderia esperar) na verdade verificado na base de código Angular para alternar alguns recursos de “depuração”, o mais evidente dos quais é a mensagem familiar registrada no console

Angular está sendo executado em modo de desenvolvimento. Chame enableProdMode() para ativar o modo de produção.

Quando a flag é true, significa que estamos executando uma fase de desenvolvimento da nossa aplicação, por isso queremos que o framework seja mais detalhado em avisos e erros, e até mesmo que seja um pouco mais “pedante” verificando situações que não sejam um erro per- sim, mas isso pode levar a um comportamento indesejado e muitas vezes errôneo na produção.
O famoso com certeza é NG0100: Expression has change after it wascheck, responsável por verificar se nossa vinculação de dados segue um fluxo unidirecional, algo que pode trazer problemas durante a execução, mas que não gerará erros por si só em tempo de execução.

Originalmente, o Angular não tinha como mudar esse sinalizador, a não ser colocar a função em um arquivo analisado no bootstrap.

Magia negra da substituição de arquivos

As pessoas tendiam a aceitar a interpretação do
arquivo correto para carregar como fé, sem questionar como o framework era capaz de ler environment.ts ou environment.prod.ts de acordo com o alvo de construção escolhido.
A resposta não foi nada que envolvesse um conhecimento profundo dos mecanismos internos do Angular, mas apenas a utilização de um recurso interessante oferecido por seu construtor, que ao analisar a configuração para o alvo escolhido, foi instruído a levar em conta o array, emitindo a substituição definida fileReplacementsem seus objetos.
Esta era a configuração padrão para construção de produção algumas versões atrás:

"configurations": {
...
  "production": {
    "fileReplacements": [
      {
        "replace": "src/environments/environment.ts",
        "with": "src/environments/environment.prod.ts"
      }
    ],
...

Nada nos impedia de adicionar novas substituições ou alterar a padrão, mas, neste último caso, deveríamos ter considerado modificar nosso main.ts arquivo para verificar no arquivo correto a environment.production propriedade usada para alternar o sinalizador de produção.

O que mudou na versão 15

A última grande versão do Angular aproveita um sistema diferente para alternar o sinalizador de produção: permite que a optimization opção do construtor, por padrão passada para production o destino de construção, defina global NgDevMode como falso, sem ter que analisar qualquer arquivo env.

Essa mudança eliminou o único motivo para ter qualquer arquivo de ambiente no início, levando os desenvolvedores a se livrar deles completamente e obviamente removendo fileReplacements ocorrências padrão na configuração dos alvos de construção.

Por que as pessoas estão pirando

Olhando para o que lemos até agora, parece que esta nova abordagem não é algo que deveria afetar a maioria dos desenvolvedores de aplicações Angular, sendo mais uma “interna” do framework.
O fato é que, sendo esses arquivos já gerados na criação do projeto e gerenciados corretamente com base no alvo de construção, tornou-se prática comum usá-los para armazenar um monte de valores que precisam ser alternados entre a produção e a construção de desenvolvimento.
Geralmente estes envolvem endereços de servidores API para contato e configurações de provedores de autenticação.

Sem encontrar os arquivos esperados nos projetos recém-gerados, pessoas que nunca se interessaram em entender como eles trabalhavam não sabiam onde colocar esses dados, desconhecendo a simplicidade de reproduzir manualmente a configuração original.

Solução Lazy

Após a enorme quantidade de reclamações sobre isso, os desenvolvedores Angular optam por “restaurar” sob demanda algo semelhante ao comportamento antigo na versão 15.1 .

Portanto, a partir dessa versão, ter os arquivos de ambiente em vigor após a criação de um projeto é tão simples quanto emitir

ng generate environments

que conforme explicado nos documentos irá criá-los e configurá-los builde serverdirecionar para usá-los.

Resumindo: ele criará src/environments/environment.ts e src/environments/environment.development.ts adicionará o último como substituto do primeiro para development o destino da configuração de construção

"development": {
...
  "fileReplacements": [
    {
      "replace": "src/environments/environment.ts",
      "with": "src/environments/environment.development.ts"
    }
  ]

Por que eles não pensaram nisso antes

O hábito de colocar variáveis ​​de ambiente dentro desses arquivos é menos simples do que parece.
Mesmo que o seu nome e a sua utilização possam levar a considerá-los o local ideal para tal informação, no cenário real estão longe de ser a melhor solução.
Dados como domínios, endpoints, portas e similares não estão vinculados apenas ao destino da construção , mas muitas vezes mais estreitamente ao contexto de implantação .
É por isso que muitas pessoas preferem mantê-los fora do processo de construção e deixar o aplicativo avaliá-los em tempo de execução como token injetado na implantação, talvez como variável de ambiente da estrutura de hospedagem ou docker bundling, lido por um processo mínimo do lado do servidor e exposto como API , ou mesmo passá-los em um arquivo de configuração dedicado inserido como ativos por pipeline, conforme explicado neste artigo incrível do bom e velho @frederikprijck .

Agora deve ficar claro que não houve nenhuma mudança no gerenciamento de variáveis ​​de ambiente pelo Angular, apenas uma atualização que fez com que uma configuração antiga e conveniente não fosse mais necessária, levando a reconsiderar o que sempre foi um hábito que muitas vezes era uma solução abaixo do ideal, mas que está disponível como sempre foi.