Executando verificação de segurança...
1

Porque não simplesmente injetar as variáveis do .env no env da máquina?

No vscode tem uma extensão que injeta o .env no terminal do VSCode

Se rodar com dokcer tem a opção --env-file que injeta automaticamente as variáveis

Com essas abordagens não precisa ler o arquivo, é só ler direto do env.

Carregando publicação patrocinada...
1

Sua observação é válida para ambientes de infraestrutura pronta, mas a proposta deste pacote é garantir que a aplicação seja autossuficiente e type-safe.

Embora ferramentas como Docker e extensões de IDE injetem variáveis como strings no processo, o dotenv resolve camadas que essas ferramentas não alcançam:

  1. Contrato de Dados (Struct Mapping): A documentação atual do pacote agora com suporte o uso de Unmarshal. Enquanto a verão antiga entrega apenas strings, a nova versão realiza o parsing automático para tipos nativos do Go (int, bool, float64), garantindo que a aplicação não suba com valores inválidos.
  2. Consistência entre Ambientes: Nem todo ambiente de execução é containerizado ou executado via IDE (ex: scripts de automação, instâncias bare-metal ou CI/CD simplificados). O pacote garante que a lógica de carregamento seja idêntica, independente de onde o binário é executado.
  3. Gestão Reversa (Marshal): O suporte a Marshal permite que a aplicação gere ou atualize arquivos .env programaticamente, algo que a injeção passiva via terminal não permite.

O objetivo é transformar o os.Environ (puramente baseado em strings) em um objeto de configuração tipado e validado, centralizando a lógica de configuração dentro do domínio da aplicação."