Oraindik Bower erabiltzen duen lan-kopia baterako, proiektuaren barruko .bowerrc batek paketeen HTTP eskaeretarako bidea eman dezake:

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

Batu proxy eremuak lehendik dagoen JSON objektuan. Mantendu proiektuaren benetako direktorio-ezarpena adibidetik desberdina bada. SET HTTP_PROXY=... bezalako shell esleipen bat ez da JSON sarrera.

proxy HTTP helmugei aplikatzen zaie; https-proxy HTTPS helmugei aplikatzen zaie. Biek HTTP proxy amaiera-puntu bera izenda dezakete. Autentifikatu gabeko bitartekari publikoak onartzen dituen bide batean pakete-deskarga publikoetarako, HTTP proxy zerrendak hautagaiak eskaintzen ditu balio horietarako. Proxyaren beraren garraio-eskema balioaren parte da.

Bowerrek konfigurazioa komando-lerroko argumentuetatik, ingurumen-aldagaietatik eta konfigurazio-fitxategietatik konbinatzen du. Beraz, proiektu-fitxategia sarrera bat da, ez azken balio eraginkorraren froga. Dokumentatutako ingurumen-formak bower_https_proxy bezalako izenak barne hartzen ditu.

Mantendu lan-direktorioa koherentea automatizazioan. Bowerrek konfigurazioa lan-direktorioaren hierarkian bilatzen du, beraz lana beste direktorio batean hastea aldatu dezake zein proiektu-fitxategik parte hartzen duen. Berreskurapena Giti eslegatzen bazaio, aztertu Git lan-kopiaren bide bereizia.

Erlazionatutako artikuluak