Для робочої копії, яка досі використовує 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.

Схожі статті