Un ghid pentru npm: Managerul de pachete Node.js

Publicat: 2022-03-11

JavaScript este cu ușurință cel mai folosit limbaj atunci când vine vorba de dezvoltarea de site-uri web și aplicații web. Multitudinea de resurse este uluitoare și, cu atât mai mult, numărul de biblioteci disponibile.

La început, aceste biblioteci sunt puține și ușor de întreținut; cu toate acestea, în curând se instalează iadul dependenței și este necesară o soluție mai matură.

npm este probabil cel mai popular manager de pachete pentru JavaScript.

Introduceți Managerul de pachete Node (npm) – un manager de pachete JavaScript utilizat în special împreună cu Node.js, deși poate fi folosit și independent. Vă oferă un control excepțional asupra dependențelor proiectului și oferă o modalitate excelentă de a contribui la lumea open-source.

Puteți începe pur și simplu rulând npm install <package name> și injectându-l în fișierul JavaScript.

Doriți să instalați o anumită versiune? Nici o problemă. Rulați npm install <package name>@1.2.3 .

Doriți să instalați un pachet la nivel global (cum ar fi Mocha sau Angular-CLI)? Doar adăugați un -g așa: npm install -g angular-cli mocha .

Desigur, majoritatea cazurilor de utilizare se opresc la o instalare npm și nu este nevoie de nimic altceva. Cu toate acestea, npm are o mulțime de caracteristici suplimentare, prin care vă voi prezenta, evidențiind pe cele pe care le consider esențiale, cu adevărat utile sau pur și simplu minunate.

comenzi CLI

CLI este locul în care utilizatorii își petrec cea mai mare parte a timpului interacționând cu npm, iar interfața sa de ajutor este de fapt utilă.

Interogarea ajutorului ( npm help ) vărsă o gamă întreagă de opțiuni, iar rularea npm help-search <searchText> vă oferă o listă cu rezultatele căutării direct de la marcarea npm.

Iată comenzile de bază care ies în evidență.

  • install : Este menționat aici din cauza necesității sale absolute atunci când lucrați cu npm. Folosit fie pentru a instala un pachet nou local, fie la nivel global (când se adaugă -g ) sau pentru a instala dependențe enumerate în fișierul package.json (mai multe despre asta mai târziu).

  • uninstall : Acesta este, de asemenea, un element esențial. Este folosit pentru a curăța un anumit pachet din directorul node_modules fie local, fie global (când se adaugă -g ).

  • access : Acesta este terenul de joacă al administratorilor de permisiuni ale utilizatorilor npm în contextul organizațiilor npm și al pachetelor (private). Chestii foarte puternice. Folosit împreună cu adduser , owner , team etc., oferă un control fin asupra cine are acces la ce.

  • bin : Unde naiba sunt instalate pachetele? Rulați această comandă pentru a vedea calea absolută a fișierului.

  • cache : Dacă începeți să instalați pachete din stânga, dreapta și centru npm, această comandă este destul de utilă. Fie apelați-o cu subcomanda ls pentru a vedea o listă de pachete stocate în cache local, fie cu subcomanda clean pentru a șterge toate pachetele care se află în cache. Când registrul npm era încă puțin instabil, acest lucru era esențial pentru a reveni la un mediu stabil sau pentru a reseta lucrurile atunci când nu ați configurat corect permisiunile npm.

  • config : Vom intra în diferitele opțiuni de configurare mai târziu, dar această comandă se ocupă în primul rând de proprietățile de configurare persistente în fișierul de configurare local sau global, folosind subcomenzile set , get sau delete .

  • dedupe sau ddp : Când lucrați la un proiect pe o perioadă lungă de timp și instalați pachete direct din npm, această comandă va parcurge arborele local de pachete și va încerca să simplifice dependențele.

  • link : Când vă dezvoltați propriul pachet npm, acest lucru vă permite să creați o legătură simbolică către contextul global, astfel încât să poată fi testat ca și cum ar fi fost instalat global din registrul npm. De exemplu, dacă scrieți un instrument de asamblare într-un nod care are un CLI instalat la nivel global, puteți rula această comandă și puteți testa comportamentul CLI fără a fi nevoie să îl implementați mai întâi.

  • ls : Este folosit pentru a vizualiza dependențele pachetelor și dependențele acestora, într-o structură arborescentă. Este mișto de văzut și este util și pentru comparații cu alte proiecte.

  • outdated : Acesta este utilizat pentru a evalua starea curentă a dependențelor instalate și dacă acestea sunt sau nu învechite. În proiectele în care lista de dependențe rădăcină are o lungime de sute de linii, o verificare manuală a pachetelor este aproape imposibilă. Adăugarea -g --depth=0 la această comandă vă permite să verificați și pachetele instalate la nivel global.

  • publish : Această comandă este esențială atunci când vă dezvoltați propriul pachet pentru npm. Face exact așa cum sugerează numele; vă publică pachetul în registrul npm.

  • search : Folosiți aceasta pentru a căuta în registru toate pachetele care conțin textul furnizat în al treilea argument.

  • shrinkwrap : Pe scurt, această comandă vă permite să blocați versiuni specifice de dependență într-un pachet în ordine, astfel încât un număr relaxat de semver (versiune semantică) să nu rupă codul de producție.

  • star : Îți place foarte mult un pachet pe care îl folosești? Utilizați această comandă pentru a vă arăta aprecierea direct din terminal, care apoi se reflectă pe pagina pachetului din registrul npm.

  • update : Aceasta urmează de obicei comenzii outdated pentru a actualiza orice pachet învechit.

  • version : Aceasta vă oferă o prescurtare pentru a elimina proprietatea versiunii package.json și a face o etichetă git într-unul singur.

Rețineți că majoritatea acestor comenzi pot lua subcomenzi și/sau configurații, iar această listă nu este în niciun caz o discuție finală despre CLI.

npm-config

Configurația este o parte majoră a npm și există mai multe moduri în care variabilele de configurare pot fi setate.

Configurare prin CLI și variabile de mediu

În primul rând, configurația poate fi setată prin intermediul CLI de la terminal.

De obicei, ar arăta cam așa: npm <command> --<configuration option> [<optional value>] .

Dacă valoarea nu este specificată, opțiunea va fi setată implicit la true.

De exemplu, să presupunem că lucrați la un pachet npm (privat) și decideți să-l publicați ca pachet public.

Acest lucru se face cu ușurință prin adăugarea --access=public la comanda dvs. de publish . Dacă nu am specificat ca proprietatea să fie publică, implicit ar fi restricționată (privată).

Configurația atașată la alte comenzi ca aceasta nu persistă peste tot, așa că poate deveni obositor să setați o serie de configurații prin intermediul CLI.

În aceste cazuri, poate fi mai bine să setați configurația folosind variabile de mediu.

Orice variabilă de mediu setată cu prefixul npm_config_ va fi utilizată pentru a configura npm.

De exemplu: export npm_config_registry=localhost:4321 ar seta opțiunea de configurare a registrului la nivel global, iar atunci când npm este executat, va folosi registrul npm situat la localhost pe portul 4321.

Configurare prin fișierul npmrc

De asemenea, puteți seta opțiuni de configurare folosind fișierul special .npmrc , care poate fi setat la diferite niveluri, în funcție de cerințele dvs.:

  • Nivel de proiect: în rădăcina codului unui proiect împreună cu fișierul package.json , de obicei path/to/project/.npmrc
  • Nivel de utilizator: directorul care configurează contul unui anumit utilizator, de obicei ~/.npmrc
  • Nivel global: directorul în care npm caută configurații globale, de obicei $PREFIX/etc/npmrc
  • Nivel încorporat: fiți precaut. Această configurație nu este doar globală, ci face și parte din codul sursă npm, iar cele mai bune practici recomandă (de fapt solicită) să nu schimbăm codul pe care nu suntem responsabili pentru menținerea. Acesta poate fi găsit de obicei la /path/to/npm/npmrc .

Setările de configurare din fișierul .npmrc pot fi modificate și menținute folosind CLI prin rularea unei comenzi în acest format: npm config set <key> <value> .

De exemplu, puteți rula npm config set access public pentru a face publică permanent configurația de publicare a unui pachet cu scop (privat).

În mod implicit, această comandă ar persista configurația local (configurația la nivel de utilizator, așa cum este descris mai sus), dar puteți adăuga -g pentru a o persista la nivel global.

Atunci când configurarea persistentă trebuie să aibă loc la nivel de proiect sau la nivel încorporat, fișierul .npmrc trebuie modificat folosind un editor de text.

Configurare prin package.json

În cele din urmă, configurația poate fi setată din fișierul package.json . Cu toate acestea, acesta este folosit rar (și ar trebui să fie folosit doar dacă este necesar în mod explicit), deoarece un fișier .npmrc la nivel de proiect este locul preferat în mod convențional pentru a seta configurația pachetului.

Setări de configurare notabile

  • access : După cum sa discutat mai sus, este folosit pentru a seta permisiunile.

  • always-auth : este important de reținut că această setare este implicit false. Când este setat la true, npm va necesita întotdeauna autentificare atunci când contactează registry.

  • ca : Valoare implicită pentru autoritatea de certificare (CA) npm. Poate fi schimbat în null pentru a permite accesul numai registratorilor cunoscuți sau la un anumit certificat CA pentru a acorda acces numai aceluia anume. Această setare, împreună cu cafile , cert și strict-ssl , sunt rareori utilizate, dar vorbesc despre aspectul de securitate și fiabilitate al npm, permițând liniștea sufletească în a ști că pachetul pe care îl instalați provine din sursa pe care o așteptați.

  • color : aceasta este implicită adevărată, oferindu-vă o pauză de la neclaritatea standard a terminalului prin colorarea stdout -ului permis de descriptorii de fișiere tty. Dacă este setat la fals, terminalul rămâne plictisitor. Când este setat la always , iese întotdeauna color.

  • depth : Această setare permite un control granular asupra a ceea ce vedeți cu comenzile recursive, cum ar fi ls și outdated , prin atribuirea cât de profund sunt executate. O valoare de 0 va evalua doar primul nivel de dependențe, în timp ce infinitul (prestabilit) va face ca toate nivelurile de dependențe să fie evaluate. Excepția de la această regulă este atunci când o outdated cu ; în acest caz, infinitul este interpretat ca 0 pentru a asigura o ieșire mai relevantă.

  • dev : Acest lucru este setat la false în mod implicit, dar când este setat la adevărat (când se face o npm install ) toate dependențele de dezvoltare din fișierul package.json vor fi instalate împreună cu dependențele normale.

  • dry-run : Când această setare este setată la true, npm nu va face nicio modificare pachetului dvs., ci vă va spune ce ar fi făcut. Acest lucru poate fi foarte util când rulați anumite comenzi, cum ar fi dedupe sau update .

  • git-tag-version : este setat implicit la true. Această setare etichetează o versiune în git când rulează comanda npm version . Dacă utilizați npm ca manager de pachete pentru un proiect mare care are versiuni etichetate în git, vă poate economisi timp și nu uitați să actualizați fișierul package.json pentru dvs.

  • loglevel : În mod implicit, acesta este setat la warn , ceea ce dă o eroare și o ieșire de avertizare la rularea comenzilor npm. Alte setări includ silent , care nu oferă nicio ieșire; error , care înregistrează numai erorile la ieșire; http , care anunță doar erori de solicitare http; info , pentru ieșire informativă dorită); verbose , care înregistrează aproape totul; și silly , care, așa cum sugerează și numele, oferă o cantitate stupidă de rezultate și apoi puțin.

  • production : când este setat la adevărat, npm acționează în consecință și rulează toate comenzile în modul producție. Aceasta înseamnă că dependențele de dezvoltare sau opționale nu vor fi instalate și nici sarcinile legate de dezvoltare nu vor fi executate.

  • rollback : când se setează la true, toate instalările eșuate sunt eliminate. Acest lucru este util atunci când o instalare de dependențe eșuează. În funcție de nivelul dvs. de înregistrare, ar trebui să puteți vedea ce instalări au eșuat, să notați acestea și să rulați comanda npm install cu opțiunea de rollback setată la true. Apoi, cu notele și o instalare uscată (așa cum este descris mai sus), puteți depana problema.

  • save : When installing a package directly from the registry, you can append –save to the command which will add the installed package to the dependencies option in the file. For example, file. For example, npm install lodash` va adăuga lodash la dependențele dvs.

  • save-dev : Similar cu opțiunea de salvare a configurației, adăugați --save-dev când instalați un pachet, iar apoi va fi adăugat la opțiunea devDependencies din fișierul package.json .

  • save-optional : Similar cu opțiunea de salvare a configurației, adăugați --save-optional atunci când instalați un pachet, iar apoi va fi adăugat la opțiunea optionalDependencies din fișierul package.json .

  • save-exact : La instalarea pachetelor, opțiunile save , save-dev și save-optional modifică fișierul package.json inserând pachetul instalat în proprietatea sa respectivă cu un operator semver range. Când se invocă setarea de configurare „save-exact” cu o valoare true, împreună cu una dintre setările menționate mai sus, se folosește un anumit număr de versiune, ignorând intervalul semver.

  • save-prefix : Aceasta setează operatorul intervalului semver când se utilizează save , save-dev sau save-optional . Valoarea implicită este ^ , permițând upgrade-uri minore ale pachetelor la instalare. Acesta poate fi setat la orice operator de interval sever prefix valid.

  • tag-version-prefix : Valoarea implicită convențională este v , specificând ce este adăugat versiunii etichetei git atunci când rulează npm version .

Actualizarea npm Utilizând npm

De asemenea, puteți utiliza npm pentru a se actualiza.

Pur și simplu rulați npm install -g npm@latest , iar npm va fi actualizat la cea mai recentă versiune stabilă. Este important să rețineți că fiecare versiune de Node.js este livrată cu o versiune specifică de npm și, din experiența mea, nu ar trebui să vă încurcați prea mult cu acea pereche.

La sfârșitul zilei, recomandarea mea este să rămâneți cu perechea așa cum sunt destinate.

Când utilizați npm ca unealtă independentă, asigurați-vă că înțelegeți implicațiile utilizării oricărei versiuni pe care o alegeți. Există un instrument excelent pentru gestionarea diferitelor versiuni Node.js (și, la rândul lor, versiuni npm) pe același sistem numit nvm.

Fișierul package.json

Fișierul package.json este elementul crucial care leagă totul împreună.

Este o cerință pentru publicarea unui pachet în registrul npm și aici prinde viață partea de gestionare a dependențelor.

Are două câmpuri obligatorii, și anume „nume” și „versiune”, iar împreună aceste proprietăți ar trebui să fie un identificator unic.

Câmpul de nume ar trebui să respecte anumite reguli, așa cum sunt definite de documentația npm privind denumirea, iar câmpul de versiune este supus specificațiilor semver.

npm citește fișierul package.json pentru gestionarea dependențelor.

În plus, puteți avea o listă de dependențe lungi de o milă și puteți defini o versiune specifică care să fie utilizată pentru fiecare dintre ele, folosind versiunile semver și operatorii de interval. Iată o listă cu alte proprietăți notabile.

"principal"

„principal” definește punctul de intrare în aplicația dvs., care este implicit index.js . În funcție de convenție sau de cadrul dvs., acesta poate fi app.js sau main.js . Poți, desigur, să faci orice vrei.

„scripte”

Aceasta este o proprietate subestimată.

În primul rând, poate fi folosit pentru a face lucruri în prepublicare.

În al doilea rând, oferă un loc în care puteți alias o serie de comenzi utilizate frecvent, variind de la sarcini de construire (definite în gulp sau grunt), declanșarea instalării altor dependențe (cu ceva de genul bower), pornirea unui server de dezvoltare cu webpack sau rulează un set de comenzi bash.

„dependențe”

Această proprietate este o listă de pachete necesare aplicației dvs., împreună cu numărul de server compatibil. Este o proprietate notabilă deoarece poate fi modificată de la terminal atunci când instalați pachete locale.

Acest lucru se face prin adăugarea --save (sau prescurtarea -S ) la sfârșitul comenzii npm install .

Când faceți acest lucru, pachetele nou instalate sunt adăugate la lista de dependențe din fișierul package.json .

În mod similar, o dependență poate fi eliminată prin adăugarea --save atunci când rulați comanda npm uninstall .

Este important să fiți conștienți de modelele de versiuni semver ale fiecărei dependențe și ce înseamnă acestea.

Dacă regula semver este prea strictă, pierdeți noile funcții și îmbunătățiri, în timp ce, dacă regula semver este prea relaxată, o versiune de rupere a unui pachet poate fi instalată de-a lungul liniei.

Instalarea unui pachet rupt se poate dovedi a fi destul de dificil de rezolvat, mai ales când este utilizată versiunea redusă a pachetului.

„Dependențe de dezvoltare”

Separată de proprietatea dependențe, proprietatea „devDependencies” vă permite să definiți dependențe care sunt utilizate numai în faza de dezvoltare și nu sunt necesare pentru construcția de producție (cum ar fi ESLint, pachetele grunt-contrib și Protractor). La fel ca în cazul dependențelor, această proprietate poate fi modificată de la terminal adăugând --save-dev (sau prescurtarea -D ) la sfârșitul comenzii npm install sau a comenzii npm uninstall . Aceeași precauție se aplică versiunilor așa cum este menționat la dependențe.

"cos"

Aici puteți specifica fișierele executabile ale pachetului dvs., cum ar fi calea către un utilitar CLI. Această proprietate îi spune npm să creeze legături simbolice locale sau globale către executabilele dvs. atunci când pachetul este instalat.

„config”

După cum sa discutat mai devreme, aici definiți setările de configurare prin fișierul package.json .

"privat"

Când este setat la true, npm va refuza să publice pachetul.

Acest lucru nu trebuie confundat cu setarea de configurare a accesului.

Aceasta este o setare utilă atunci când aveți un proiect care utilizează npm împreună cu pachetul package.json , dar nu este destinat să fie publicat în registrul npm, fie în domeniul de aplicare, fie public.

Dacă intenția dvs. se schimbă, schimbați pur și simplu setarea la false și veți putea publica pachetul.

Proprietăți personalizate

Fișierul package.json acceptă și proprietăți personalizate, atâta timp cât numele nu este deja definit sau rezervat.

Dezvoltarea propriului pachet npm

Ecosistemul npm este plin de pachete, scrise de mii de dezvoltatori diferiți din întreaga lume. Fiecare rezolvă un fel de problemă, oferind o abstractizare sau prezentând o implementare a ceva.

Sunt șanse ca, la un moment dat, și tu să vrei să-ți dezvolți propriul pachet de partajat.

Mai întâi, trebuie să creați un fișier package.json cu proprietățile minime necesare de „nume” și „versiune”, apoi proprietatea „principală” pentru a specifica punctul de intrare, de exemplu index.js.

Scrieți codul în acel fișier index.js, conectați-vă cu contul de utilizator npm sau creați un utilizator nou de pe terminal și sunteți gata să îl publicați în registrul npm.

Pachetele pot fi publice sau private.

Pachetele publice sunt publicate gratuit și sunt disponibile pentru utilizare pentru toată lumea.

Pachetele private, numite pachete cu scop, pot fi publicate numai dacă ați plătit un utilizator de module private și pot fi identificate prin @username/ care este adăugat înaintea numelui pachetului.

Pachetele acoperite pot fi publicate public și prin apelarea comenzii publish cu --access=public .

În plus, dacă petreceți mai mult timp extinzând și îmbunătățind baza de cod a pachetului și este timpul ca o nouă versiune să fie publicată, pur și simplu modificați versiunea (conform regulilor și convenției semver) a pachetului în package.json . fișier și tastați npm publish .

De asemenea, puteți utiliza interfața de linie de comandă și puteți apela npm version <update_type> , unde update_type este fie patch , minor , sau major , așa cum este descris de semver, iar acest lucru crește automat numărul versiunii din fișierul package.json .

npm Organizații

Din nou, documentația npm pentru aceasta este excelentă și ar fi inutil să le repeți doar cuvintele.

Ceea ce se poate spune despre organizații în contextul npm este că este extrem de fin și, atunci când sunt gestionate corect, echipele și indivizii mari, care lucrează la pachete definite sau publice sub un singur nume, pot fi foarte bine gestionate și restricționate.

Deși este complex de stăpânit, este foarte plină de satisfacții.

Puterea lui npm

În cele din urmă, documentația pe care npm o furnizează este extinsă și ar trebui consultată pentru detalii, dar acest articol oferă o prezentare utilă atât a funcționalității de bază, cât și a celor mai avansate, implicate, transmițând minunatia lui npm.

Ca în toate lucrurile, există opinii puternice și pot fi găsite multe defecte. Dar dacă nu ați încercat niciodată npm (sau node, de altfel), plonjați și explorați-l singur. Sunt șanse să vă bucurați mai mult decât credeți.

Pentru mai multe articole interesante despre npm, luați în considerare citirea Utilizarea Scala.js cu npm și Browserify.