Наладка проксі праекта Bower у .bowerrc

Трымайце запісы HTTP- і HTTPS-проксі Bower у сапраўднай канфігурацыі .bowerrc унутры праекта.

Для працоўнай копіі, якая ўсё яшчэ выкарыстоўвае Bower, .bowerrc унутры праекта можа забяспечыць маршрут для HTTP-запытаў пакетаў:

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

Далучыце палі проксі да існуючага аб'екта JSON. Захавайце фактычную наладу каталога праекта, калі яна адрозніваецца ад прыкладу. Прысваенне ў абалонцы накшталт SET HTTP_PROXY=... не з'яўляецца запісам JSON.

proxy дзейнічае для HTTP-прызначэнняў; https-proxy дзейнічае для HTTPS-прызначэнняў. Абодва могуць называць адну і тую ж канчатковую кропку HTTP-проксі. Для публічных загрузак пакетаў на маршруце, які дазваляе неаўтэнтыфікаваных публічных пасярэднікаў, спіс HTTP-проксі прапануе кандыдатаў для гэтых значэнняў. Уласная схема транспарту проксі ўваходзіць у значэнне.

Bower аб'ядноўвае канфігурацыю з аргументаў каманднага радка, зменных асяроддзя і файлаў канфігурацыі. Таму файл праекта — гэта толькі адзін уваход, а не доказ канчатковага дзейнага значэння. Задакументаваная форма асяроддзя ўключае такія імёны, як bower_https_proxy.

Захоўвайце працоўны каталог пастаянным пры аўтаматызацыі. Bower шукае канфігурацыю ў іерархіі працоўнага каталога, таму запуск задачы ў іншым каталозе можа змяніць, які файл праекта ўдзельнічае. Калі атрыманне перадаецца Git, праверце асобны маршрут працоўнай копіі Git.

Падобныя артыкулы