Para una copia de trabajo que aún usa Bower, un .bowerrc dentro del proyecto puede proporcionar la ruta para las solicitudes HTTP de los paquetes:

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

Combina los campos de proxy en el objeto JSON existente. Conserva la configuración real del directorio del proyecto si difiere del ejemplo. Una asignación de shell como SET HTTP_PROXY=... no es una entrada JSON.

proxy se aplica a destinos HTTP; https-proxy se aplica a destinos HTTPS. Ambos pueden nombrar el mismo punto de conexión de proxy HTTP. Para descargas públicas de paquetes en una ruta que permite intermediarios públicos no autenticados, la lista de proxies HTTP ofrece candidatos para esos valores. El esquema de transporte del propio proxy forma parte del valor.

Bower combina la configuración de argumentos de línea de comandos, variables de entorno y archivos de configuración. Por lo tanto, un archivo de proyecto es una entrada, no una prueba del valor efectivo final. La forma documentada del entorno incluye nombres como bower_https_proxy.

Mantén el directorio de trabajo coherente en la automatización. Bower busca la configuración en la jerarquía del directorio de trabajo, así que iniciar la tarea en otro directorio puede cambiar qué archivo de proyecto participa. Si la obtención se delega a Git, revisa la ruta separada de la copia de Git.

Artículos relacionados