npm-prokurilaj agordoj por HTTP kaj HTTPS

Agordu la HTTP- kaj HTTPS-prokurilajn vojojn de npm, komprenu noproxy-esceptojn kaj uzu privatan CA sen malŝalti TLS-kontrolon.

npm havas apartajn agordojn proxy kaj https-proxy. La distingo estas la petata celo. Por ordinara HTTP-prokurilo kiu tunelas HTTPS, ambaŭ valoroj povas montri al la sama http://-finpunkto.

Projekt-nivela .npmrc povas enhavi:

proxy=http://203.0.113.10:8080
https-proxy=http://203.0.113.10:8080
noproxy=localhost,127.0.0.1,registry.example.internal

Anstataŭigu la dokumentan finpunkton per via prokurilo; por permesitaj testoj de publikaj registrejoj, la listo de HTTP-prokuriloj provizas HTTP-kandidatojn. La lasta linio intence lasas la nomitan internan registrejon rekta. Ĝi ne estas alia prokurila adreso.

Petu npm fari peton

Instalado el kaŝmemoro estas malbona vojtesto: npm eble jam havas ĉion bezonatan. Registreja ping estas pli malgranda kontrolo:

npm ping --registry=https://registry.npmjs.org/

Sukcesa finiĝo montras ke ĉi tiu npm-alvoko atingis tiun registrejan vojon. Ĝi ne pruvas ke ĉiu tarball-gastiganto, Git-dependeco aŭ aparta pakaĵmastrumila procezo uzas la saman vojon.

Por trovi konfliktan agordon, inspektu la efektivajn valorojn anstataŭ tuj redakti pliajn dosierojn:

npm config get proxy
npm config get https-proxy
npm config get noproxy

Tiuj komandoj povas eligi ensalutilojn se ili estas enmetitaj en URL. Inspektu la eligon loke anstataŭ alglui ĝin senŝanĝe en problemraporton.

Projekta .npmrc ne estas uzata por tutmondaj instaladoj. Se nur npm install -g malsukcesas, kontrolu la efektivan agordon de tiu alvoko anstataŭ supozi ke ĝi legis la projektdosieron.

Kontrolu esceptojn antaŭ ol ŝanĝi la IP

npm ankaŭ uzas prokurilajn mediovariablojn, kaj ĝia agordo noproxy povas veni de NO_PROXY. Celo esceptita de la efektiva agordo povas konektiĝi rekte malgraŭ ekzistanta prokurila valoro. Male, forigi linion el unu .npmrc ne forigas hereditan mediovariablon.

Tenu atestilerarojn apartaj

Rajtigita inspekta prokurilo eble bezonas organizan CA, al kiu via Node/npm-agordo ankoraŭ ne fidas. npm subtenas CA-dosieron:

cafile=/path/to/approved-ca-bundle.pem
strict-ssl=true

Uzu la veran aprobitan atestilaron por tiu medio. Agordi strict-ssl=false malfortigas atestilkontrolon; ĝi ne anstataŭas elekton de la ĝusta prokurilo aŭ fidmaterialo.

Kiam testado finiĝas, forigu la projektajn superregojn aldonitajn kaj denove kontrolu la efektivajn valorojn. Tio lasas la projekton heredi sian antaŭan agordon sen ŝanĝi aliajn projektojn sur la sama maŝino.

Rilataj artikoloj