Para uma cópia de trabalho que ainda usa Bower, um .bowerrc dentro do projeto pode fornecer a rota para os pedidos HTTP dos pacotes:

{
  "directory": "bower_components",
  "proxy": "http://proxy.example.net:8080",
  "https-proxy": "http://proxy.example.net:8080"
}

Combine os campos de proxy no objeto JSON existente. Preserve a definição real do diretório do projeto se diferir do exemplo. Uma atribuição de shell como SET HTTP_PROXY=... não é uma entrada JSON.

proxy aplica-se a destinos HTTP; https-proxy aplica-se a destinos HTTPS. Ambos podem nomear o mesmo ponto final de proxy HTTP. Para transferências públicas de pacotes numa rota que permite intermediários públicos não autenticados, a lista de proxies HTTP oferece candidatos para esses valores. O próprio esquema de transporte do proxy faz parte do valor.

O Bower combina configuração de argumentos de linha de comandos, variáveis de ambiente e ficheiros de configuração. Um ficheiro de projeto é, portanto, uma entrada, não a prova do valor efetivo final. A forma documentada de ambiente inclui nomes como bower_https_proxy.

Mantenha o diretório de trabalho consistente na automatização. O Bower procura a configuração na hierarquia do diretório de trabalho, pelo que iniciar a tarefa noutro diretório pode alterar que ficheiro de projeto participa. Se a obtenção for delegada ao Git, examine a rota separada da cópia Git.

Artigos relacionados