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=...-ის მსგავსი shell-ის მინიჭება JSON ჩანაწერი არ არის.

proxy ვრცელდება HTTP დანიშნულებებზე; https-proxy ვრცელდება HTTPS დანიშნულებებზე. ორივემ შეიძლება დაასახელოს ერთი და იგივე HTTP პროქსის საბოლოო წერტილი. არაავტორიზებული საჯარო შუამავლების დაშვების მარშრუტზე საჯარო პაკეტების ჩამოტვირთვისთვის HTTP პროქსების სია გთავაზობთ კანდიდატებს ამ მნიშვნელობებისთვის. თავად პროქსის სატრანსპორტო სქემა მნიშვნელობის ნაწილია.

Bower აერთიანებს კონფიგურაციას ბრძანების ხაზის არგუმენტებიდან, გარემოს ცვლადებიდან და კონფიგურაციის ფაილებიდან. ამიტომ პროექტის ფაილი ერთი შეყვანაა და არა საბოლოო ეფექტური მნიშვნელობის დამადასტურებელი. დოკუმენტირებული გარემოს ფორმა მოიცავს სახელებს, როგორიცაა bower_https_proxy.

ავტომატიზაციაში სამუშაო დირექტორია შეინახეთ თანმიმდევრული. Bower კონფიგურაციას ეძებს სამუშაო დირექტორიის იერარქიაში, ამიტომ სამუშაოს სხვა დირექტორიაში დაწყებამ შეიძლება შეცვალოს, რომელი პროექტის ფაილი მონაწილეობს. თუ მიღება Git-ს გადაეცემა, შეამოწმეთ Git-ის ცალკე სამუშაო ასლის მარშრუტი.