Para unha copia de traballo que aínda usa Bower, un .bowerrc dentro do proxecto pode fornecer a ruta para as solicitudes HTTP dos paquetes:

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

Combina os campos de proxy no obxecto JSON existente. Conserva a configuración real do directorio do proxecto se difire do exemplo. Unha asignación de shell como SET HTTP_PROXY=... non é unha entrada JSON.

proxy aplícase a destinos HTTP; https-proxy aplícase a destinos HTTPS. Ambos poden nomear o mesmo punto de conexión de proxy HTTP. Para descargas públicas de paquetes nunha ruta que permite intermediarios públicos non autenticados, a lista de proxies HTTP ofrece candidatos para eses valores. O esquema de transporte do propio proxy forma parte do valor.

Bower combina a configuración de argumentos da liña de ordes, variables de contorno e ficheiros de configuración. Un ficheiro de proxecto é, polo tanto, unha entrada, non unha proba do valor efectivo final. A forma documentada do contorno inclúe nomes como bower_https_proxy.

Mantén o directorio de traballo coherente na automatización. Bower busca a configuración na xerarquía do directorio de traballo, así que iniciar a tarefa noutro directorio pode cambiar que ficheiro de proxecto participa. Se a obtención se delega a Git, revisa a ruta separada da copia de Git.

Artigos relacionados