Vanlige npm-problemer og hvordan du fikser dem trygt

Home » Python » Vanlige npm-problemer og hvordan du fikser dem trygt

Det kan være utrolig frustrerende å støte på rare npm-problemer, spesielt når alt du ville var å installere en pakke og komme tilbake til koding. Fra PowerShell-blokkeringsskript på Windows, til tillatelsesmareritt på Linux, til endeløse lister over sårbarheter i revisjonsrapporten din, kan npm-feil raskt utvikle seg til timer med tapt produktivitet hvis du ikke vet hva du ser på.

Denne veiledningen tar deg gjennom de vanligste problemene i den virkelige verden når du bruker npm, forklarer hvorfor de oppstår, og gir deg praktiske, velprøvde løsninger. Vi skal se på Windows-utførelsespolicyer, globale tillatelsesfeil, sikkerhetsfallgruver i npm-økosystemet, forskjellen mellom utviklings- og produksjonssårbarheter, hva npm ci virkelig gjør det, og hvordan man feilsøker ødelagte installasjoner og hurtigbufferproblemer uten å få panikk.

PowerShell-kjøringspolicy som blokkerer npm på Windows

En av de første hindringene mange Windows-brukere møter etter å ha installert Node.js er at npm rett og slett nekter å kjøre i PowerShell. Terminalen gir en feilmelding i stil med «kan ikke laste inn filen». C:\Program Files\nodejs\npm.ps1 fordi kjøring av skript er deaktivert på dette systemet», sammen med en PSSecurityException og et forslag til lesing about_Execution_Policies.

Dette problemet har ingenting å gjøre med en dårlig Node.js-installasjon; det er en PowerShell-sikkerhetsfunksjon kalt utførelsespolicy. Som standard forhindrer noen Windows-oppsett at lokale skript (inkludert npms egen PowerShell-innpakning) kjører, noe som gjør at PowerShell behandler npm.ps1 som potensielt usikkert innhold.

For å fikse dette må du vanligvis lempe på PowerShell-kjøringspolicyen for den nåværende brukeren, i stedet for å deaktivere sikkerheten helt på systemnivå. En vanlig metode er å kjøre PowerShell som administrator og bruke en kommando som Set-ExecutionPolicy RemoteSigned -Scope CurrentUser, som tillater lokalt opprettede skript samtidig som det blokkerer usignerte eksterne skript.

Hvis du foretrekker å ikke endre PowerShell-policyen i det hele tatt, kan du omgå dette ved å bruke ledeteksten (cmd.exe) eller Windows Terminal med et annet skall. I disse miljøene går ikke npm gjennom et PowerShell-skript, så begrensningen gjelder ikke, og din npm Kommandoer skal kjøre så lenge Node.js er riktig lagt til i PATH-filen din.

Hva npm ci egentlig gjør og hvorfor det er viktig

Når npm kjører, er en annen kommando som ofte reiser spørsmål npm ci, som oppfører seg annerledes enn den mer kjente npm install. Mens begge installerer avhengigheter, npm ci er spesielt utviklet for rene, reproduserbare miljøer som kontinuerlige integrasjonsrørledninger (CI).

Den viktigste forskjellen er det npm ci ignorerer versjonsområder i package.json og installerer nøyaktig de versjonene som er festet i package-lock.json. Det betyr at ingen «kompatible, men nyere» avhengighetsversjoner sniker seg inn i bygget ditt bare fordi de ble publisert senere; hver installasjon er deterministisk så lenge låsefilen forblir den samme.

Fra et ytelsesperspektiv, npm ci er vanligvis raskere for CI fordi den hopper over visse trinn for avhengighetsløsning og antar et blankt ark. Den forventer at din node_modules katalogen er enten tom eller vil bli slettet, noe som lar npm unngå mange ekstra kontroller og oppdateringer som npm install normalt ville opptre.

Fra et sikkerhets- og forsyningskjedeperspektiv, npm ci reduserer drastisk risikoen for at ureviderte avhengighetsendringer glir inn i produksjonsbyggene dine. Siden den aldri ser etter nyere kompatible versjoner, fryser du effektivt avhengighetstreet ditt til det teamet ditt har låst og revidert, noe som gjør hendelsesreproduksjon og sårbarhetsanalyse mye enklere.

Sikkerhetsfokuserte team slår seg ofte sammen npm ci med automatiserte verktøy for avhengighetsskanning som inspiserer hver pakke, inkludert de som er låst i package-lock.json filen. På den måten, selv om låsefilen din var ren da den ble utført, kan nylig oppdagede sårbarheter eller skadelige pakker fortsatt bli fanget under CI-byggingen før applikasjonen distribueres.

Globale npm-tillatelser og regelen «aldri bruk sudo npm»

På Unix-lignende systemer (Linux, macOS) kommer en av de mest beryktede kategoriene av npm-problemer fra installasjon av globale pakker med forhøyede rettigheter. Hvis du noen gang har sett advarsler som «Mangler skrivetilgang til /usr/lib/node_modules"eller feil som EACCES: permission denied, du har støtt på denne typen problemer.

Som standard prøver npm ofte å legge globalt installerte pakker under /usr (for eksempel /usr/lib/node_modules og kjørbare filer i /usr/bin), som er systemkataloger som vanligvis eies av root. Når brukere begynner å kjøre sudo npm install -g ... For å «fikse» tillatelsesfeil blir filer og mapper eid av root, noe som fører til at senere kommandoer som kjøres som en vanlig bruker, støter på problemer med skrivetilgang.

Den store konklusjonen er enkel: ikke kjør npm som root og unngå å bruke sudo med npm med mindre du er helt sikker på hva du gjør. I tillegg til kaos med tillatelser, øker installasjon av tredjeparts JavaScript som root også virkningen av skadelige eller kompromitterte pakker, noe som gir dem full kontroll over systemet ditt.

For å sjekke hvor npm for øyeblikket plasserer globale pakker, kan du kjøre npm config get prefix, som vanligvis returnerer noe sånt som /usr på et problematisk oppsett. Det prefikset bestemmer hvor globale moduler og binærfilene deres havner, så hvis prefikset peker på en systemsti, er tillatelsesproblemer nesten uunngåelige i det lange løp.

En trygg, anbefalt løsning er å flytte det globale npm-prefikset inne i brukerens hjemmekatalog, hvor du har full kontroll uten utvidede rettigheter. Et typisk mønster er å opprette en katalog som ~/.npm-global og så løpe npm config set prefix '~/.npm-global' slik at alle fremtidige globale installasjoner lander der i stedet for i /usr.

Etter at du har endret prefikset, må du legge til den nye globale binærkatalogen i PATH-banen din, slik at systemet kan finne globalt installerte kommandoer. For eksempel kan du legge til en linje som export PATH=~/.npm-global/bin:$PATH til shell-oppstartsfilen din (for eksempel ~/.bashrc or ~/.zshrc), og start deretter terminalen på nytt slik at endringen trer i kraft.

Når dette er riktig konfigurert, kjøres det på nytt npm doctor blir en god mental kontroll: den skal rapportere at hurtigbufrede filer og globale node_modules er lesbare og skrivbare av din nåværende bruker. Merk at når du bytter til en ny global katalog, vil tidligere installerte globale pakker ikke lenger være til stede, og du må installere de du faktisk bruker på nytt.

Bruk av npm doctor til å diagnostisere miljøproblemer

Mange npm-hodepiner er ikke forårsaket av et spesifikt prosjekt, men av et ødelagt eller inkonsekvent npm-miljø på maskinen din. Kommandoen npm doctor er bygget nettopp for dette: den kjører et sett med helsesjekker på npm-oppsettet ditt og fremhever potensielle problemer.

Når du utfører npm doctor, npm tester tilkoblingen til registeret, verifiserer npm- og Node.js-versjonene dine, sjekker den konfigurerte register-URL-en din og inspiserer tillatelser på hurtigbuffermapper og globale modulkataloger. Hver sjekk rapporteres med statusen «ok» eller «ikke ok», noe som gjør det enkelt å oppdage feilkonfigurasjoner.

Hvis for eksempel npm finner ut at kataloger som /usr/lib/node_modules or /root/.npm ikke er skrivbare for den vanlige brukeren, vil du se tillatelsesrelaterte elementer merket som «ikke OK» i rødt. Det er et sterkt hint om at npm tidligere ble kjørt som root eller via sudo, og etterlater root-eide filer som blokkerer normal drift.

Doctor-kommandoen kan også avsløre manglende verktøy som npm forventer, for eksempel Git, som kreves av noen avhengigheter som bruker Git-URL-er i stedet for publiserte registerpakker. Hvis Git ikke er installert eller ikke er i PATH-banen din, vil du se en advarsel som ber deg om å installere det og prøve på nytt.

Etter å ha fikset eventuelle problemer npm doctor rapporter, og hvis du kjører den på nytt, bør alle grønne «ok»-statuser vises, noe som indikerer en fungerende npm-installasjon. Behandle denne kommandoen som en grunnleggende helsesjekk når du mistenker at den systemomfattende npm-konfigurasjonen din kan være årsaken til merkelige feil du ser under installasjoner eller revisjoner.

Hvor skjørt npm-økosystemet kan være: kjente hendelser og risikoer

Utover lokale konfigurasjonsproblemer, er det viktig å forstå at npm som et økosystem har sine egne strukturelle risikoer, drevet av enorme avhengighetstrær og i stor grad frivillige vedlikeholdere. Moderne JavaScript-prosjekter henter ofte inn hundrevis eller til og med tusenvis av pakker, mange vedlikeholdes av bare én eller to personer på fritiden.

Denne ekstreme fragmenteringen gjør det nesten umulig å manuelt gjennomgå alt som havner i den endelige søknaden din, noe som åpner døren for forsyningskjedeangrep på npm og subtile sårbarheter. En enkelt kompromittert eller forlatt pakke kan kaskadere gjennom avhengighetsgrafen og påvirke et enormt antall prosjekter uten at utviklere innser det med en gang.

Et klassisk eksempel på denne sårbarheten er hendelsen i 2016 som involverte en liten pakke kalt left-pad, som besto av omtrent 11 linjer med kode. Dens eneste formål var å fylle ut strenger til venstre med et tegn til de nådde en gitt lengde, men den ble brukt, direkte og indirekte, av utallige pakker og store verktøy som Babel JavaScript-kompilatoren.

Etter en tvist mellom forfatteren og npm bestemte vedlikeholderen seg for å avpublisere flere av pakkene hans, inkludert left-pad, fra registeret. Fordi npm ikke oppbevarte uforanderlige øyeblikksbilder av publiserte versjoner på den tiden, ødela fjerningen umiddelbart bygg over hele verden som var avhengige av disse versjonene, og etterlot utviklere sittende fast med mislykkede installasjoner.

I et enestående trekk gjenopprettet npm Inc. den siste kjente versjonen av left-pad seg selv, uten forfatterens samtykke, for å få økosystemet på beina igjen. Den avgjørelsen var kontroversiell fordi den motsa ideen om at forfattere kontrollerer livssyklusen til pakkene sine, men den fremhevet også hvor mye kritisk infrastruktur hadde blitt avhengig av trivielle tredjepartsmoduler.

Utover tilgjengelighetshendelser har det vært en rekke sikkerhetsfokuserte tilfeller der populære npm-pakker har blitt kompromittert eller funnet å inneholde alvorlige sårbarheter. Disse inkluderer scenarier der vedlikeholdere ble sosialt modifisert, eierskap til forlatte pakker ble kapret, eller subtile feil ble utnyttet til å kjøre vilkårlig kode.

Et mye omtalt eksempel er 2018 event-stream kompromiss, der en angriper fikk kontroll over et populært strømmeverktøy og injiserte kode som hadde som mål å stjele kryptovaluta fra berørte applikasjoner. Fordi event-stream var en avhengighet i mange andre pakker, forplantet den skadelige koden seg stille gjennom avhengighetskjeder til produksjonssystemer.

Et annet tilfelle er sårbarheten for kommandoinjeksjon fra 2019 i coa, en CLI-hjelper som brukes av diverse kjente verktøy. Under visse forhold kan feilaktig renset brukerinput bli omgjort til vilkårlige skallkommandoer, noe som åpner døren for ekstern kjøring hvis sårbarheten ble utløst i en sårbar kontekst.

Høyprofilerte biblioteker som axios har også hatt sårbarheter, for eksempel problemer med forfalskning av serversideforespørsler (SSRF) som lar angripere omdirigere servere for å sende forespørsler til interne ressurser. Selv svært vanlige verktøy som minimist ble påvirket av prototypeforurensningsfeil, noe som gjorde det mulig for angripere å tukle med objektprototyper og potensielt endre applikasjonsatferd på subtile og farlige måter.

Hovedlærdommen er at selv svært populære eller tilsynelatende ufarlige pakker ikke automatisk er trygge; de ​​kan utnyttes, forlates eller feilkonfigureres som all annen programvare. Derfor krever en sunn sikkerhetsstilling rundt npm både tekniske verktøy (revisjoner, skanning, låsing) og kulturelle vaner (regelmessige oppdateringer, nøye valg av avhengigheter og en preferanse for å skrive enkle verktøy internt når det er mulig).

Sårbarheter i utviklings- kontra produksjonsmiljøer

Når utviklere kjører for første gang npm audit På et prosjekt kan den lange listen over sårbarheter se skremmende ut, men ikke alle påvirker faktisk den kjørende produksjonsapplikasjonen din. Mange flaggede problemer finnes i verktøy som bare brukes under utviklings- eller byggetid.

Hovedforskjellen ligger mellom avhengigheter som er erklært under dependencies og de under devDependencies in package.json. Pakker inn devDependencies er vanligvis bare nødvendige for oppgaver som bunting, transpiling, linting eller kjøring av testservere, og de er ikke ment å sendes som en del av den endelige produksjonspakken eller serverkjøringen.

For eksempel sårbarheter i verktøy som webpack-dev-server, @angular-devkiteller vite vanligvis viktig mens du utvikler lokalt, ikke når produksjonsbygget ditt er distribuert. Disse utviklingsserverne og byggeverktøyene kan eksponere angrepsflater som kodelekkasjer på tvers av opprinnelsessteder eller SSRF-lignende oppførsel, men bare så lenge utviklingsserveren kjører aktivt og er tilgjengelig.

Kjører en vanlig npm audit Rapporten vil vanligvis inkludere både kjøretids- og utviklingssårbarheter, og viser problemer i pakker som brace-expansion, esbuildog webpack-dev-server. Revisjonen vil ofte foreslå npm audit fix eller enda npm audit fix --force å oppgradere versjoner, noe som noen ganger krever store oppdateringer i rammeverk som Angular for å bli kvitt advarslene.

For å se hvilke sårbarheter som faktisk påvirker det som distribueres til produksjon, kan du kjøre npm audit --production (eller bruk den anbefalte --omit=dev alternativ i nyere npm-versjoner). Hvis denne kommandoen returnerer «funnet 0 sårbarheter», betyr det at, så vidt npms rådgivningsdatabase kjenner til, er produksjonssettet ditt med avhengigheter for øyeblikket fritt for kjente problemer.

Dette betyr ikke at du kan ignorere sårbarheter kun for utviklere for alltid, fordi de fortsatt kan sette utviklernes maskiner eller kildekode i fare mens de jobber med prosjektet. Men å forstå forskjellen lar deg prioritere: fiks store produksjonsproblemer først, og takl deretter problemer i utviklingsmiljøet på en planlagt måte i stedet for å reagere på alle advarsler som om de var like kritiske.

Hvordan npm-revisjonsfiks fungerer og når man bør unngå –force

Kommandoen npm audit fix er utviklet for å automatisk oppgradere sårbare avhengigheter innenfor sikre versjonsområder, men det er ikke en magisk knapp som løser alt uten kompromisser. Den går gjennom avhengighetstreet ditt og leter etter pakker med kjente problemer, og prøver å oppgradere dem til oppdaterte versjoner som forblir kompatible med dine eksisterende. package.json begrensninger.

Hvis for eksempel en avhengighet er spesifisert som ^1.2.0, npm vil prøve å flytte til den nyeste 1.x versjon som inneholder rettelsen, uten å hoppe rett til 2.x, noe som kan introdusere avbrytende endringer. Dette gjør npm audit fix relativt trygt for mange prosjekter, ettersom det respekterer semantiske versjonsbegrensninger.

Noen ganger er imidlertid de eneste tilgjengelige oppdateringene i nyere hovedversjoner eller i verktøykjeder som krever bredere oppgraderinger, og det er da npm foreslår å bruke npm audit fix --force. Dette flagget forteller npm at det er tillatt å installere potensielt brytende oppdateringer, inkludert større versjonsoppdateringer og kaskaderende endringer i rammeverk eller byggeverktøy.

Blind løping --force i et stort eller eldre prosjekt kan enkelt ødelegge bygg eller forårsake subtile regresjoner under kjøretid, fordi avhengigheter som koden din er avhengig av kan endre atferd eller API-er. Tenk på det som å velge en mini-migrering av stacken din, ikke bare en sikkerhetsoppdatering, så det bør gjøres med sikkerhetsnett for testing og versjonskontroll på plass.

Det finnes også tilfeller der npm rett og slett ikke kan fikse alle sårbarheter automatisk, vanligvis fordi de nødvendige versjonsoppgraderingene ville komme i konflikt med andre begrensninger i avhengighetsgrafen din. I slike situasjoner må du kanskje oppdatere eller erstatte bestemte biblioteker manuelt, eller akseptere et midlertidig risikonivå inntil en sikkerhetsoppdatering publiseres.

En praktisk strategi er først å forstå hvilke sårbarheter som påvirker produksjonen, deretter anvende npm audit fix uten --force, og vurder kun tvungne eller større oppgraderinger etter konsekvensanalyse og med tilstrekkelig testdekning. På den måten holder du applikasjonen din sikker uten å stadig destabilisere kodebasen din i jakten på en helt ren revisjonsrapport.

Til syvende og sist er håndtering av npm-sårbarheter en kontinuerlig prosess med risikovurdering, prioritering og kontrollerte oppdateringer, ikke en engangskommando du kjører og glemmer. Hvert problem må veies ut fra alvorlighetsgrad, reell utnyttbarhet i din kontekst og kostnaden ved å oppgradere de berørte pakkene eller verktøykjedene.

Tenk på nytt hvor mange npm-avhengigheter du egentlig trenger

En av de mest effektive langsiktige sikkerhetspraksisene med npm er rett og slett å stole på færre tredjepartspakker der du med rimelighet kan. Hver ekstra avhengighet øker angrepsflaten, vedlikeholdsbyrden og potensialet for overraskende transitive problemer senere.

Utviklere installerer ofte pakker av bekvemmelighetsgrunner, selv når funksjonaliteten kunne implementeres i en håndfull linjer med vanlig JavaScript. Over tid kan denne vanen fylle avhengighetstreet ditt med moduler som knapt brukes, dårlig vedlikeholdes eller lett erstattes av små biter med intern kode.

Å redusere avhengigheter har flere fordeler utover sikkerhet: mindre prosjekter, raskere installasjons- og byggetider, færre versjonskonflikter og enklere feilsøking når noe går i stykker. En slankere avhengighetsgraf gjør det også enklere å revidere hva som faktisk går inn i applikasjonen din, i stedet for å vasse gjennom sider med midlertidige pakker du aldri bevisst valgte.

Fra et risikoperspektiv betyr færre bevegelige deler færre sjanser for at forlatte prosjekter, kompromitterte vedlikeholdere eller subtile sårbarheter i obskure verktøy kan påvirke stacken din. Selv om du ikke kan unngå store rammeverk eller kjernebiblioteker, kan du fortsatt være selektiv når det gjelder små hjelpere som utfører trivielle oppgaver, som ofte står for en overraskende andel av revisjonsstøyen.

En moden avhengighetsstrategi innebærer å evaluere nye pakker kritisk, fjerne ubrukte pakker med jevne mellomrom, og favorisere velholdte, bredt kontrollerte biblioteker fremfor nisje- eller engangsløsninger når det er mulig. Kombinert med god bruk av npm audit, npm ci, og regelmessige oppdateringer, kan denne tankegangen dramatisk redusere hyppigheten og alvorlighetsgraden av npm-relaterte problemer du møter.

Feilsøking av npm-feil, logger og korrupte installasjoner

Selv med et godt konfigurert miljø og et lean-avhengighetstre, vil du til slutt støte på forvirrende npm-feil som stopper arbeidsflyten din fra å starte. Effektiv feilsøking starter med å få mer informasjon om hva npm faktisk gjør under panseret når en kommando mislykkes.

En enkel teknikk er å øke npms ordrikhet ved å bruke flagg som --dd (eller --loglevel verbose), som skriver ut detaljerte trinn i prosessen. Dette loggingsnivået kan avsløre nøyaktig hvilken operasjon som mislyktes, hvilken fil eller katalog som forårsaket problemer, eller hvilket skript i avhengighetskjeden din som ikke fungerer.

Når en kommando mislykkes, forteller npm deg vanligvis også hvor den lagret en mer detaljert loggfil, vanligvis under en katalog som ~/.npm/_logs. Når du åpner den loggen, får du et kronologisk spor av installasjonen eller skriptkjøringen, inkludert stakkspor, miljødetaljer og underliggende systemfeil som ikke alltid vises i den korte feilutdataen.

Noen feil kommer fra dine egne feil package.json, for eksempel ugyldig JSON, feil skriptnavn eller feil utformede versjonsområder. I slike tilfeller kan det å nøye undersøke filen for syntaksfeil, skrivefeil eller etterfølgende komma løse problemer som ellers ser mystiske ut ved første øyekast.

Andre ganger ligger rotårsaken på operativsystem- eller verktøynivå: problemer med nettverkstilgang, DNS-oppløsning, brannmurregler eller feilkonfigurerte Git- eller GitHub-legitimasjon. Hvis for eksempel en avhengighet hentes direkte fra et Git-repository og Git mangler eller er feilkonfigurert, vil npm mislykkes selv om selve registeret er tilgjengelig.

Problemer med avhengighetsinstallasjon kan også skyldes en korrupt node_modules katalog eller npm-cache, spesielt etter avbrutte installasjoner eller halvfullførte oppgraderinger. Hvis du mistenker korrupsjon, er det ofte enklere å fjerne det. node_modules og låsefilen, tøm npm-hurtigbufferen og installer på nytt, i stedet for å prøve å fikse individuelle ødelagte pakker på plass.

Et vanlig gjenopprettingsmønster er å slette node_modules, eventuelt kjøre en hurtigbufferrensingskommando, og deretter utfør npm install igjen for å gjenoppbygge avhengighetstreet fra bunnen av. Denne tunghendte tilbakestillingen fjerner ofte merkelig eller inkonsekvent oppførsel som vanlig feilsøking ikke fanger opp, spesielt etter at man har byttet grener eller slått sammen store avhengighetsendringer.

Husk at ikke alle feil er direkte forårsaket av npm selv; noen stammer fra skriptene som pakkene kjører under installasjonen eller i ditt eget prosjekts livssykluskroker. De detaljerte loggene og feilstakksporene kan hjelpe deg med å avgjøre om du har å gjøre med et rent npm-problem eller et problem i et tredjepartsskript eller tilpasset verktøy som tilfeldigvis utløses via npm.

Alt i alt, en kombinasjon av bedre logging, nøye lesing av feilmeldinger og sporadisk tilbakestilling av node_modules vil hjelpe deg med å gjenopprette fra de fleste npm-feil uten å bli sittende fast i endeløse prøving og feiling-sykluser. Over tid vil du gjenkjenne tilbakevendende mønstre – JSON-skrivefeil, tillatelsesproblemer, manglende verktøy – som gjør den neste feilsøkingsøkten mye raskere.

Å administrere npm på en vellykket måte handler til syvende og sist om å forstå både de lokale verktøyegenskapene og de bredere økosystemrisikoene: fra PowerShell-utførelsespolicyer og Unix-tillatelser, via deterministiske installasjoner og sårbarhetsrevisjoner, til forsiktig avhengighetsvalg og systematisk feilsøking, reduserer hver god praksis du tar i bruk sjansene for at npm-problemer vil spore av utviklingsarbeidet ditt.