Configurer le proxy du projet Bower dans .bowerrc

Pour une copie de travail qui utilise encore Bower, un .bowerrc dans le projet peut fournir la route des requêtes HTTP des paquets :

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

Fusionnez les champs de proxy dans l'objet JSON existant. Conservez le réglage réel du répertoire du projet s'il diffère de l'exemple. Une affectation de shell comme SET HTTP_PROXY=... n'est pas une entrée JSON.

proxy s'applique aux destinations HTTP ; https-proxy s'applique aux destinations HTTPS. Les deux peuvent désigner le même point de terminaison de proxy HTTP. Pour les téléchargements publics de paquets sur une route autorisant des intermédiaires publics non authentifiés, la liste de proxys HTTP propose des candidats pour ces valeurs. Le schéma de transport du proxy lui-même fait partie de la valeur.

Bower combine la configuration issue des arguments de ligne de commande, des variables d'environnement et des fichiers de configuration. Un fichier de projet n'est donc qu'une entrée, pas la preuve de la valeur effective finale. La forme d'environnement documentée comprend des noms tels que bower_https_proxy.

Gardez le répertoire de travail cohérent dans l'automatisation. Bower recherche la configuration dans la hiérarchie du répertoire de travail, si bien que démarrer la tâche dans un autre répertoire peut changer le fichier de projet qui participe. Si la récupération est déléguée à Git, examinez la route distincte de la copie Git.