Problemes comuns de npm i com solucionar-los de manera segura

Inici » Pitó » Problemes comuns de npm i com solucionar-los de manera segura

Trobar-se amb problemes estranys de npm pot ser increïblement frustrant, sobretot quan tot el que volies era instal·lar un paquet i tornar a programar. Des de scripts de bloqueig de PowerShell a Windows fins a malsons de permisos a Linux, passant per llistes interminables de vulnerabilitats a l'informe d'auditoria, els errors de npm poden convertir-se ràpidament en hores de pèrdua de productivitat si no sabeu què esteu mirant.

Aquesta guia us guiarà pels problemes més comuns del món real quan feu servir npm, explica per què es produeixen i us ofereix solucions pràctiques i provades. Analitzarem les polítiques d'execució de Windows, els errors de permisos globals, els errors de seguretat en l'ecosistema npm, la diferència entre les vulnerabilitats de desenvolupament i producció, què... npm ci realment ho fa, i com depurar instal·lacions fallides i problemes de memòria cau sense entrar en pànic.

La política d'execució de PowerShell bloqueja npm a Windows

Un dels primers obstacles que molts usuaris de Windows troben després d'instal·lar Node.js és que npm simplement es nega a executar-se a PowerShell. El terminal mostra un error semblant a "no es pot carregar el fitxer". C:\Program Files\nodejs\npm.ps1 perquè l'execució de scripts està desactivada en aquest sistema", juntament amb un PSSecurityException i una recomanació de lectura about_Execution_Policies.

Aquest problema no té res a veure amb una instal·lació incorrecta de Node.js; és una característica de seguretat de PowerShell anomenada política d'execució. Per defecte, algunes configuracions de Windows impedeixen que s'executi cap script local (inclòs el propi contenidor de PowerShell de npm), cosa que fa que PowerShell tracti npm.ps1 com a contingut potencialment insegur.

Per solucionar-ho, normalment cal relaxar la política d'execució de PowerShell per a l'usuari actual, en comptes de desactivar la seguretat completament a nivell de sistema. Un mètode habitual és executar el PowerShell com a administrador i utilitzar una ordre com ara Set-ExecutionPolicy RemoteSigned -Scope CurrentUser, que permet scripts creats localment i alhora bloqueja els remots sense signar.

Si preferiu no canviar la política del PowerShell en absolut, podeu solucionar-ho mitjançant la línia d'ordres (cmd.exe) o el terminal de Windows amb una shell diferent. En aquests entorns, npm no passa per un script de PowerShell, de manera que la restricció no s'aplica i el vostre npm Les ordres s'haurien d'executar sempre que Node.js s'afegeixi correctament al vostre PATH.

Què fa realment NPM CI i per què és important

Un cop npm s'està executant, una altra ordre que sovint planteja preguntes és npm ci, que es comporta de manera diferent del més conegut npm install. Mentre tots dos instal·len dependències, npm ci està dissenyat específicament per a entorns nets i reproduïbles com ara les pipelines d'integració contínua (CI).

La diferència clau és que npm ci ignora els intervals de versions a package.json i instal·la exactament les versions fixades package-lock.json. Això vol dir que no s'introdueixen versions de dependències "compatibles però més noves" a la vostra compilació només perquè s'han publicat més tard; cada instal·lació és determinista sempre que el fitxer de bloqueig es mantingui igual.

Des d'una perspectiva de rendiment, npm ci normalment és més ràpid per a CI perquè omet certs passos de resolució de dependències i assumeix un nou començament. S'espera que el vostre node_modules el directori està buit o s'esborrarà, cosa que permet a npm evitar moltes comprovacions i actualitzacions addicionals que npm install normalment actuaria.

Des del punt de vista de la seguretat i la cadena de subministrament, npm ci redueix dràsticament el risc que els canvis de dependències no revisats s'infiltrin en les compilacions de producció. Com que mai busca versions compatibles més noves, esteu congelant l'arbre de dependències al que el vostre equip ha bloquejat i auditat, cosa que facilita molt la reproducció d'incidents i l'anàlisi de vulnerabilitats.

Els equips centrats en la seguretat sovint es combinen npm ci amb eines automatitzades d'escaneig de dependències que inspeccionen tots els paquets, inclosos els que estan bloquejats a package-lock.json arxiu. D'aquesta manera, fins i tot si el fitxer de bloqueig estava net quan es va fer el commit, les vulnerabilitats recentment descobertes o els paquets maliciosos encara es poden detectar durant la compilació de CI abans que es desplegui l'aplicació.

Permisos globals de npm i la regla "no utilitzar mai sudo npm"

En sistemes tipus Unix (Linux, macOS), una de les categories més notòries de problemes amb npm prové de la instal·lació de paquets globals amb privilegis elevats. Si alguna vegada heu vist avisos com ara "Falta accés d'escriptura a /usr/lib/node_modules"o errors com ara EACCES: permission denied, t'has trobat amb aquest tipus de problema.

Per defecte, npm sovint intenta posar els paquets instal·lats globalment sota /usr (per exemple /usr/lib/node_modules i executables en /usr/bin), que són directoris de sistema que normalment pertanyen a l'usuari root. Quan els usuaris comencen a executar sudo npm install -g ... per "corregir" errors de permisos, els fitxers i directoris passen a ser propietat de root, cosa que fa que les ordres posteriors executades com a usuari normal tinguin problemes d'accés d'escriptura.

La conclusió principal és simple: no executeu npm com a root i eviteu utilitzar sudo amb npm tret que estiguis absolutament segur del que estàs fent. A més del caos de permisos, instal·lar JavaScript de tercers com a root també augmenta l'impacte de qualsevol paquet maliciós o compromès, donant-li un control total sobre el vostre sistema.

Per comprovar on npm col·loca actualment els paquets globals, podeu executar npm config get prefix, que normalment retornarà alguna cosa semblant a /usr en una configuració problemàtica. Aquest prefix determina on acaben els mòduls globals i els seus binaris, de manera que si el prefix apunta a una ruta del sistema, els problemes de permisos són gairebé inevitables a la llarga.

Una solució segura i recomanada és moure el prefix global npm dins del directori d'inici de l'usuari, on teniu control total sense privilegis elevats. Un patró típic és crear un directori com ara ~/.npm-global i després córrer npm config set prefix '~/.npm-global' perquè totes les futures instal·lacions globals aterrin allà en comptes de dins /usr.

Després de canviar el prefix, heu d'afegir el nou directori de binaris globals al vostre PATH perquè el sistema pugui trobar les ordres instal·lades globalment. Per exemple, podeu afegir una línia com ara export PATH=~/.npm-global/bin:$PATH al fitxer d'inici del shell (com ara ~/.bashrc or ~/.zshrc), després reinicieu el terminal perquè el canvi tingui efecte.

Un cop configurat correctament, tornar a executar npm doctor esdevé una bona comprovació de seguretat: hauria d'informar que els fitxers emmagatzemats a la memòria cau i els fitxers globals node_modules són llegibles i escrivibles per l'usuari actual. Tingueu en compte que quan canvieu a un directori global nou, els paquets globals instal·lats anteriorment ja no hi seran i haureu de reinstal·lar els que realment feu servir.

Ús de npm doctor per diagnosticar problemes d'entorn

Molts mals de cap de npm no són causats per un projecte específic, sinó per un entorn npm trencat o inconsistent a la vostra màquina. L'ordre npm doctor està creat exactament per a això: executa un conjunt de comprovacions d'estat de la configuració de npm i destaca els possibles problemes.

Quan executeu npm doctor, npm comprova la connectivitat amb el registre, verifica les versions de npm i Node.js, comprova l'URL del registre configurat i inspecciona els permisos a les carpetes de memòria cau i als directoris globals de mòduls. Cada comprovació es notifica amb un estat "correcte" o "no correcte", cosa que facilita la detecció de configuracions incorrectes.

Per exemple, si npm troba directoris com ara /usr/lib/node_modules or /root/.npm no són escrivibles per l'usuari normal, veureu els elements relacionats amb els permisos marcats com a "notOk" en vermell. Això és un bon indici que npm s'executava anteriorment com a root o via sudo, deixant enrere fitxers propietat de root que bloquegen les operacions normals.

L'ordre doctor també pot revelar eines que falten que npm espera, com ara Git, que és necessari per algunes dependències que utilitzen URL de Git en lloc de paquets de registre publicats. Si el Git no està instal·lat o no està al vostre PATH, veureu un avís que us demanarà que l'instal·leu i que ho torneu a intentar.

Després de solucionar qualsevol problema npm doctor informes, si s'executa de nou, tots els estats "ok" en verd haurien de mostrar-se, cosa que indica una instal·lació de npm correcta. Tracteu aquesta ordre com una comprovació bàsica de l'estat sempre que sospiteu que la configuració npm de tot el sistema pot ser la causa d'errors estranys que observeu durant les instal·lacions o auditories.

Com de fràgil pot ser l'ecosistema de la NPM: incidents i riscos famosos

Més enllà dels problemes de configuració local, és important entendre que npm com a ecosistema té els seus propis riscos estructurals, impulsats per enormes arbres de dependències i mantenidors en gran part voluntaris. Els projectes moderns de JavaScript sovint utilitzen centenars o fins i tot milers de paquets, molts dels quals són mantinguts per només una o dues persones en el seu temps lliure.

Aquesta fragmentació extrema fa que sigui gairebé impossible revisar manualment tot el que acaba a la sol·licitud final, cosa que obre la porta a atacs a la cadena de subministrament contra npm i vulnerabilitats subtils. Un sol paquet compromès o abandonat pot anar en cascada a través del graf de dependències i afectar un nombre massiu de projectes sense que els desenvolupadors se n'adonin immediatament.

Un exemple clàssic d'aquesta fragilitat és l'incident del 2016 relacionat amb un petit paquet anomenat left-pad, que constava d'aproximadament 11 línies de codi. El seu únic propòsit era omplir les cadenes de l'esquerra amb un caràcter fins que arribessin a una longitud determinada, però va ser utilitzat, directament i indirectament, per innombrables paquets i eines importants com el compilador Babel de JavaScript.

Després d'una disputa entre l'autor i npm, el mantenidor va decidir anul·lar la publicació de diversos dels seus paquets, incloent-hi left-pad, del registre. Com que npm no conservava instantànies immutables de les versions publicades en aquell moment, l'eliminació va trencar instantàniament les compilacions de tot el món que depenien d'aquestes versions exactes, deixant els desenvolupadors atrapats amb instal·lacions fallides.

En una acció sense precedents, npm Inc. va restaurar l'última versió coneguda de left-pad ells mateixos, sense el consentiment de l'autor, per tornar a posar en marxa l'ecosistema. Aquesta decisió va ser controvertida perquè contradeia la idea que els autors controlaven el cicle de vida dels seus paquets, però també va destacar fins a quin punt la infraestructura crítica havia arribat a dependre de mòduls trivials de tercers.

Més enllà dels incidents de disponibilitat, hi ha hagut nombrosos casos centrats en la seguretat en què paquets npm populars es van veure compromesos o es va descobrir que contenien vulnerabilitats greus. Això inclou escenaris en què els mantenidors van ser modificats socialment, la propietat dels paquets abandonats va ser segrestada o errors subtils van ser explotats per executar codi arbitrari.

Un exemple àmpliament comentat és el del 2018 event-stream compromís, on un atacant va obtenir el control d'una popular utilitat de streaming i va injectar codi destinat a robar criptomoneda de les aplicacions afectades. perquè event-stream era una dependència en molts altres paquets, el codi maliciós es propagava silenciosament a través de cadenes de dependències als sistemes de producció.

Un altre cas és la vulnerabilitat d'injecció de comandes del 2019 a coa, un auxiliar de CLI utilitzat per diverses eines conegudes. En determinades condicions, l'entrada de l'usuari incorrectament sanejada es podria transformar en ordres de shell arbitràries, obrint la porta a l'execució remota si la vulnerabilitat s'activava en un context vulnerable.

Biblioteques d'alt perfil com ara axios també han tingut vulnerabilitats, com ara problemes de falsificació de sol·licituds del costat del servidor (SSRF) que permeten als atacants redirigir els servidors per fer sol·licituds a recursos interns. Fins i tot utilitats ultracomunes com ara minimist es van veure afectats per errors de contaminació de prototips, cosa que va permetre als atacants manipular prototips d'objectes i potencialment alterar el comportament de les aplicacions de maneres subtils i perilloses.

La lliçó principal és que fins i tot els paquets molt populars o aparentment inofensius no són automàticament segurs; poden ser explotats, abandonats o mal configurats com qualsevol altre programari. És per això que una postura de seguretat saludable al voltant de npm requereix tant eines tècniques (auditories, escaneig, bloqueig) com hàbits culturals (actualitzacions regulars, selecció acurada de dependències i preferència per escriure utilitats senzilles internament quan sigui possible).

Vulnerabilitats en entorns de desenvolupament vs. producció

Quan els desenvolupadors executen per primera vegada npm audit En un projecte, la llarga llista de vulnerabilitats pot semblar terrorífica, però no totes afecten realment l'aplicació de producció en execució. Molts dels problemes marcats es troben en eines que només s'utilitzen durant el desenvolupament o el temps de compilació.

La distinció clau rau entre les dependències declarades sota dependencies i els que estan sota devDependencies in package.json. Paquets a devDependencies normalment només es necessiten per a tasques com ara l'agrupació, la transpilació, el linting o l'execució de servidors de prova, i no estan pensats per ser enviats com a part del paquet de producció final o del temps d'execució del servidor.

Per exemple, vulnerabilitats en eines com ara webpack-dev-server, @angular-devkit, O vite generalment importa mentre es desenvolupa localment, no un cop s'ha implementat la versió de producció. Aquests servidors de desenvolupament i eines de compilació poden exposar superfícies d'atac com ara fuites de codi entre orígens o comportaments similars a SSRF, però només mentre el servidor de desenvolupament estigui en funcionament i sigui accessible.

Córrer una plana npm audit l'informe normalment inclourà vulnerabilitats tant en temps d'execució com només en desenvolupament, mostrant problemes en paquets com ara brace-expansion, esbuildi webpack-dev-server. L'auditoria sovint suggerirà npm audit fix o fins i tot npm audit fix --force a versions bump, de vegades requerint actualitzacions importants en frameworks com Angular per eliminar els avisos.

Per veure quines vulnerabilitats realment afecten el que es desplega a la producció, podeu executar npm audit --production (o utilitzeu el recomanat --omit=dev opció en versions més noves de npm). Si aquesta ordre retorna "s'han trobat 0 vulnerabilitats", vol dir que, pel que sap la base de dades d'assessors de npm, el vostre conjunt de dependències de producció actualment no té problemes coneguts.

Això no vol dir que pugueu ignorar les vulnerabilitats només per a desenvolupadors per sempre, perquè encara poden posar en risc les màquines o el codi font dels desenvolupadors mentre treballen en el projecte. Tanmateix, entendre la diferència us permet prioritzar: solucionar primer els problemes de producció d'alt impacte i després abordar els problemes de l'entorn de desenvolupament de manera planificada en lloc de reaccionar a cada avís com si fos igualment crític.

Com funciona la correcció d'auditoria npm i quan cal evitar-la –force

L'ordre npm audit fix està dissenyat per actualitzar automàticament les dependències vulnerables dins dels rangs de versions segurs, però no és un botó màgic que ho resolgui tot sense compromisos. Recorre el vostre arbre de dependències buscant paquets amb problemes coneguts i intenta augmentar-los a versions actualitzades que siguin compatibles amb les vostres dependències existents. package.json restriccions.

Per exemple, si s'especifica una dependència com a ^1.2.0, npm intentarà passar a l'última versió 1.x versió que conté la correcció, sense saltar directament a 2.x, que podrien introduir canvis decisius. Això fa npm audit fix relativament segur per a molts projectes, ja que respecta les restriccions de versionament semàntic.

De vegades, però, els únics pegats disponibles són en versions principals més noves o en cadenes d'eines que requereixen actualitzacions més àmplies, que és quan npm suggereix utilitzar npm audit fix --force. Aquesta bandera indica a npm que pot instal·lar actualitzacions potencialment ineficaces, incloent-hi canvis importants en versions i canvis en cascada en frameworks o eines de compilació.

Corrent a cegues --force en un projecte gran o antic pot trencar fàcilment les compilacions o causar regressions subtils en temps d'execució, perquè les dependències en què es basa el codi poden canviar el comportament o les API. Pensa-hi com si optessis per una minimigració de la teva pila, no només un pegat de seguretat, així que s'hauria de fer amb xarxes de seguretat de proves i control de versions implementades.

També hi ha casos en què npm simplement no pot corregir automàticament totes les vulnerabilitats, normalment perquè les actualitzacions de versió necessàries entrarien en conflicte amb altres restriccions del gràfic de dependències. En aquestes situacions, és possible que hàgiu d'actualitzar o substituir manualment certes biblioteques o acceptar un nivell de risc temporal fins que es publiqui un pegat inalterable.

Una estratègia pràctica és primer entendre quines vulnerabilitats afecten la producció i després aplicar-la npm audit fix sense --forcei només considerar actualitzacions forçades o importants després d'una anàlisi d'impacte i amb una cobertura de proves adequada. D'aquesta manera, manteniu la vostra aplicació segura sense desestabilitzar constantment la vostra base de codi en nom de la recerca d'un informe d'auditoria perfectament net.

En definitiva, tractar les vulnerabilitats de npm és un procés continu d'avaluació de riscos, priorització i actualitzacions controlades, no una ordre puntual que s'executa i s'oblida. Cal ponderar cada problema per la seva gravetat, la seva explotabilitat en el vostre context i el cost d'actualitzar els paquets o les cadenes d'eines afectades.

Repensar quantes dependències npm realment necessiteu

Una de les pràctiques de seguretat a llarg termini més efectives amb npm és simplement dependre de menys paquets de tercers sempre que sigui raonablement possible. Cada dependència addicional augmenta la superfície d'atac, la càrrega de manteniment i el potencial de problemes transitius sorprenents en el futur.

Els desenvolupadors sovint instal·len paquets per comoditat, fins i tot quan la funcionalitat es podria implementar en un grapat de línies de JavaScript simple. Amb el temps, aquest hàbit pot inflar l'arbre de dependències amb mòduls que gairebé no s'utilitzen, es mantenen malament o es poden substituir fàcilment per petits fragments de codi intern.

Reduir les dependències té múltiples beneficis més enllà de la seguretat: projectes més petits, temps d'instal·lació i compilació més ràpids, menys conflictes de versions i una depuració més senzilla quan alguna cosa falla. Un gràfic de dependències més àgil també facilita l'auditoria del que realment s'inclou a l'aplicació, en lloc de passar per pàgines de paquets transitoris que mai no heu triat conscientment.

Des d'una perspectiva de risc, menys parts mòbils signifiquen menys possibilitats que projectes abandonats, mantenidors compromesos o vulnerabilitats subtils en utilitats obscures afectin la vostra pila. Fins i tot si no podeu evitar grans marcs de treball o biblioteques bàsiques, encara podeu ser selectius amb els petits ajudants que fan tasques trivials, que sovint representen una part sorprenent del soroll d'auditoria.

Una estratègia de dependències madures implica avaluar críticament els paquets nous, eliminar periòdicament els que no s'utilitzen i afavorir biblioteques ben mantingudes i àmpliament revisades per sobre de solucions de nínxol o puntuals sempre que sigui possible. Combinat amb un bon ús de npm audit, npm cii actualitzacions periòdiques, aquesta mentalitat pot reduir dràsticament la freqüència i la gravetat dels problemes relacionats amb npm als quals us enfronteu.

Depuració d'errors, registres i instal·lacions corruptes de npm

Fins i tot amb un entorn ben configurat i un arbre de dependències senzill, acabaràs trobant errors npm confusos que aturaran el teu flux de treball de cop. Una depuració eficaç comença per obtenir més informació sobre què fa realment npm quan una ordre falla.

Una tècnica senzilla és augmentar la verbositat de npm utilitzant senyaladors com ara --dd (o --loglevel verbose), que imprimeix els passos detallats del procés. Aquest nivell de registre pot revelar exactament quina operació ha fallat, quin fitxer o directori ha causat problemes o quin script de la cadena de dependències s'està trencant.

Sempre que una ordre falla, npm també sol indicar on ha emmagatzemat un fitxer de registre més detallat, normalment en un directori com ara ~/.npm/_logs. En obrir aquest registre, obtindreu un seguiment cronològic de la instal·lació o de l'execució de l'script, incloent-hi els seguiments de la pila, els detalls de l'entorn i els errors del sistema subjacents que no sempre apareixen a la sortida d'error breu.

Alguns fracassos provenen d'errors propis package.json, com ara JSON no vàlid, noms de script incorrectes o intervals de versions amb format incorrecte. En aquests casos, tornar a examinar acuradament el fitxer per detectar errors de sintaxi, faltes tipogràfiques o comes finals pot resoldre problemes que d'altra manera semblen misteriosos a primera vista.

Altres vegades, la causa principal es troba a nivell de sistema operatiu o d'eina: problemes amb l'accés a la xarxa, la resolució DNS, les regles del tallafocs o les credencials de Git o GitHub mal configurades. Per exemple, si una dependència s'extreu directament d'un repositori de Git i falta Git o està mal configurat, npm fallarà encara que el registre en si sigui accessible.

Els problemes d'instal·lació de dependències també poden derivar-se d'un fitxer corrupte node_modules directori o memòria cau npm, especialment després d'instal·lacions interrompudes o actualitzacions a mig completar. Si sospiteu de corrupció, sovint és més fàcil eliminar-la node_modules i el fitxer de bloqueig, esborreu la memòria cau de npm i reinstal·leu-lo, en lloc d'intentar arreglar paquets trencats individuals al seu lloc.

Un patró de recuperació comú és suprimir node_modules, opcionalment executeu una ordre de neteja de memòria cau i, a continuació, executeu-la npm install de nou per reconstruir l'arbre de dependències des de zero. Aquest restabliment de mà dura sovint elimina comportaments estranys o inconsistents que la resolució de problemes habitual no detecta, especialment després de canviar de branca o fusionar grans canvis de dependències.

Recordeu que no tots els errors són causats directament per npm; alguns s'originen en els scripts que els paquets executen durant la instal·lació o en els hooks del cicle de vida del vostre propi projecte. Els registres detallats i les traces de la pila d'errors us poden ajudar a determinar si esteu tractant un problema pur de npm o un problema en un script de tercers o eines personalitzades que s'activa mitjançant npm.

En general, combinant un millor registre, una lectura acurada dels missatges d'error i el reinici ocasional de node_modules t'ajudarà a recuperar-te de la majoria d'errors de npm sense quedar-te atrapat en cicles interminables de prova i error. Amb el temps, reconeixereu patrons recurrents (errors tipogràfics de JSON, problemes de permisos, eines que falten) que faran que la següent sessió de depuració sigui molt més ràpida.

Gestionar amb èxit npm es basa, en última instància, en comprendre tant les peculiaritats de les eines locals com els riscos més amplis de l'ecosistema: des de les polítiques d'execució de PowerShell i els permisos d'Unix, passant per instal·lacions deterministes i auditories de vulnerabilitats, fins a la selecció prudent de dependències i la depuració sistemàtica, cada bona pràctica que adopteu redueix les possibilitats que els problemes de npm facin descarrilar el vostre treball de desenvolupament.