Per una copia di lavoro che usa ancora Bower, un .bowerrc nel progetto può fornire il percorso per le richieste HTTP dei pacchetti:

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

Unisci i campi proxy nell'oggetto JSON esistente. Conserva l'impostazione reale della directory del progetto se differisce dall'esempio. Un'assegnazione di shell come SET HTTP_PROXY=... non è una voce JSON.

proxy si applica alle destinazioni HTTP; https-proxy si applica alle destinazioni HTTPS. Entrambi possono indicare lo stesso endpoint del proxy HTTP. Per i download pubblici dei pacchetti su un percorso che consente intermediari pubblici non autenticati, l'elenco di proxy HTTP offre candidati per quei valori. Lo schema di trasporto del proxy stesso fa parte del valore.

Bower combina la configurazione da argomenti della riga di comando, variabili d'ambiente e file di configurazione. Un file di progetto è quindi un solo input, non la prova del valore effettivo finale. La forma documentata dell'ambiente include nomi come bower_https_proxy.

Mantieni coerente la directory di lavoro nell'automazione. Bower cerca la configurazione nella gerarchia della directory di lavoro, quindi avviare il lavoro in un'altra directory può cambiare quale file di progetto partecipa. Se il recupero è delegato a Git, esamina il percorso separato della copia Git.

Articoli correlati