Konfigurimi i përfaqësuesit të projektit Bower në .bowerrc

Mbani hyrjet e përfaqësuesit HTTP dhe HTTPS të Bower në një konfigurim .bowerrc të vlefshëm brenda projektit.

Për një kopje pune që ende përdor Bower, një .bowerrc brenda projektit mund të sigurojë rrugën për kërkesat HTTP të paketave:

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

Bashkoni fushat e përfaqësuesit në objektin JSON ekzistues. Ruani cilësimin real të drejtorisë së projektit nëse ndryshon nga shembulli. Një caktim në shell si SET HTTP_PROXY=... nuk është hyrje JSON.

proxy zbatohet për destinacionet HTTP; https-proxy zbatohet për destinacionet HTTPS. Të dy mund të emërtojnë të njëjtin pikë fundore të përfaqësuesit HTTP. Për shkarkime publike paketash në një rrugë që lejon ndërmjetës publikë të paautentikuar, lista e përfaqësuesve HTTP ofron kandidatë për ato vlera. Skema e transportit e vetë përfaqësuesit është pjesë e vlerës.

Bower kombinon konfigurimin nga argumentet e rreshtit të komandës, variablat e mjedisit dhe skedarët e konfigurimit. Prandaj një skedar projekti është një hyrje, jo provë e vlerës efektive përfundimtare. Forma e dokumentuar e mjedisit përfshin emra si bower_https_proxy.

Mbani drejtorinë e punës konsistente në automatizim. Bower kërkon konfigurimin në hierarkinë e drejtorisë së punës, kështu që nisja e punës në një drejtori tjetër mund të ndryshojë cili skedar projekti merr pjesë. Nëse marrja delegohet te Git, shqyrtoni rrugën e veçantë të kopjes së punës Git.

Artikuj të ngjashëm