برای یک نسخه کاری که هنوز از 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 را بررسی کنید.

مقالات مرتبط