Przewodnik po npm: Menedżer pakietów Node.js

JavaScript jest z pewnością najczęściej używanym językiem, jeśli chodzi o tworzenie stron internetowych i aplikacji internetowych. Mnogość zasobów jest zdumiewająca, a tym bardziej liczba dostępnych bibliotek.

Na początku tych bibliotek jest niewiele i są one łatwe w utrzymaniu; jednak wkrótce zaczyna się piekło zależności i potrzebne jest bardziej dojrzałe rozwiązanie.

Wpisz Node Package Manager (npm) – menedżer pakietów JavaScript używany najczęściej w połączeniu z Node.js, chociaż może być używany również niezależnie. Daje ci wyjątkową kontrolę nad zależnościami twojego projektu i zapewnia świetny sposób na przyczynienie się do świata open-source.

Aby rozpocząć, wystarczy uruchomić npm install <package name> i wstrzyknąć go do pliku JavaScript.

Chcesz zainstalować konkretną wersję? Nie ma problemu. Uruchom npm install <package name>@1.2.3 .

Chcesz zainstalować pakiet globalnie (np. Mocha lub Angular-CLI)? Wystarczy dodać -g w ten sposób: npm install -g angular-cli mocha .

Trzeba przyznać, że większość przypadków użycia kończy się na instalacji npm i nie ma potrzeby niczego innego. Jednak npm ma mnóstwo dodatkowych funkcji, przez które przeprowadzę Cię, podkreślając te, które uważam za niezbędne, naprawdę przydatne lub po prostu niesamowite.

Polecenia CLI

Interfejs CLI to miejsce, w którym użytkownicy spędzają większość czasu na interakcji z npm, a jego interfejs pomocy jest rzeczywiście pomocny.

Zapytanie o pomoc ( npm help ) wyrzuca całą tablicę opcji, a uruchomienie npm help-search <searchText> daje listę wyników wyszukiwania bezpośrednio ze znacznika npm.

Oto najważniejsze polecenia, które się wyróżniają.

• install : Jest tu wspomniany ze względu na jego czystą konieczność podczas pracy z npm. Służy do instalowania nowego pakietu lokalnie lub globalnie (podczas dodawania -g ) lub do instalowania zależności wymienionych w pliku package.json (więcej na ten temat później).

• uninstall : To również jest niezbędne. Służy do usuwania określonego pakietu z katalogu node_modules lokalnie lub globalnie (podczas dodawania -g ).

• access : jest to plac zabaw administratorów uprawnień użytkownika npm w kontekście pakietów npm-organisations i objętych zakresem (prywatnych). Poważnie potężny materiał. Używany w połączeniu z adduser , owner , team , itp. daje precyzyjną kontrolę nad tym, kto ma dostęp do czego.

• bin : Gdzie na ziemi są zainstalowane pakiety? Uruchom to polecenie, aby zobaczyć bezwzględną ścieżkę do pliku.

• cache : Jeśli zaczniesz instalować pakiety od npm lewego, prawego i środkowego, to polecenie jest całkiem przydatne. Wywołaj go za pomocą podkomendy ls , aby zobaczyć listę lokalnie buforowanych pakietów, lub za pomocą podkomendy clean , aby wyczyścić wszystkie pakiety znajdujące się w pamięci podręcznej. Kiedy rejestr npm był wciąż nieco niestabilny, było to niezbędne, aby wrócić do stabilnego środowiska lub zresetować rzeczy, gdy nie skonfigurowałeś poprawnie uprawnień npm.

• config : Później przejdziemy do różnych opcji konfiguracyjnych, ale to polecenie zajmuje się przede wszystkim utrwalaniem właściwości konfiguracyjnych w lokalnym lub globalnym pliku konfiguracyjnym za pomocą podkomend set , get lub delete .

• dedupe lub ddp : podczas pracy nad projektem przez dłuższy czas i instalowania pakietów bezpośrednio z npm, to polecenie przejdzie do lokalnego drzewa pakietów i spróbuje uprościć zależności.

• link : podczas tworzenia własnego pakietu npm umożliwia to utworzenie dowiązania symbolicznego do kontekstu globalnego, dzięki czemu można go przetestować tak, jakby był zainstalowany globalnie z rejestru npm. Na przykład, jeśli piszesz narzędzie do montażu w węźle, który ma globalnie zainstalowany interfejs wiersza polecenia, możesz uruchomić to polecenie i przetestować zachowanie interfejsu wiersza polecenia bez konieczności jego uprzedniego wdrażania.

• ls : Służy do wizualizacji zależności pakietów i ich zależności w strukturze drzewa. Fajnie to zobaczyć i przydaje się również do porównań z innymi projektami.

• outdated : służy do oceny bieżącego stanu zainstalowanych zależności oraz tego, czy są one nieaktualne. W projektach, w których główna lista zależności ma setki wierszy, ręczne sprawdzenie pakietów jest prawie niemożliwe. Dodanie -g --depth=0 do tego polecenia umożliwia również sprawdzenie globalnie zainstalowanych pakietów.

• publish : To polecenie jest niezbędne podczas tworzenia własnego pakietu dla npm. Robi dokładnie tak, jak sugeruje nazwa; publikuje pakiet w rejestrze npm.

• search : Użyj tego, aby wyszukać w rejestrze wszystkie pakiety zawierające tekst podany w trzecim argumencie.

• shrinkwrap : Krótko mówiąc, to polecenie pozwala zablokować określone wersje zależności w pakiecie w kolejności, tak aby zrelaksowany numer semver (wersjonowanie semantyczne) nie złamał kodu produkcyjnego.

• star : Czy naprawdę podoba ci się pakiet, którego używasz? Użyj tego polecenia, aby pokazać swoje uznanie bezpośrednio z terminala, co zostanie odzwierciedlone na stronie pakietu w rejestrze npm.

• update : zwykle następuje po outdated poleceniu aktualizacji wszelkich nieaktualnych pakietów.

• version : daje to skrót do podbicia właściwości wersji package.json i wykonania tagu git w jednym.

Zauważ, że większość z tych poleceń może przyjmować podkomendy i/lub konfiguracje, a ta lista w żadnym wypadku nie jest ostateczną dyskusją na temat CLI.

npm-config

Konfiguracja jest główną częścią npm i istnieje wiele sposobów ustawiania zmiennych konfiguracyjnych.

Konfiguracja przez CLI i zmienne środowiskowe

Po pierwsze, konfigurację można ustawić za pomocą CLI z terminala.

Zazwyczaj wyglądałoby to mniej więcej tak: npm <command> --<configuration option> [<optional value>] .

Jeśli wartość nie zostanie określona, ​​opcja zostanie domyślnie ustawiona na true.

Załóżmy na przykład, że pracujesz z ograniczonym (prywatnym) pakietem npm i decydujesz się opublikować go jako pakiet publiczny.

Można to łatwo zrobić, dołączając --access=public do polecenia publish . Gdybyśmy nie określili, że właściwość ma być publiczna, wartość domyślna byłaby ograniczona (prywatna).

Konfiguracja dołączona do innych poleceń, takich jak ta, nie jest zachowywana wszędzie, więc ustawianie szeregu konfiguracji za pomocą CLI może być męczące.

W takich przypadkach może być lepiej ustawić konfigurację przy użyciu zmiennych środowiskowych.

Każda zmienna środowiskowa ustawiona z prefiksem npm_config_ zostanie użyta do skonfigurowania npm.

Na przykład: export npm_config_registry=localhost:4321 ustawi opcję konfiguracji rejestru globalnie, a po wykonaniu npm użyje rejestru npm znajdującego się na localhost na porcie 4321.

Konfiguracja za pomocą pliku npmrc

Możesz także ustawić opcje konfiguracyjne za pomocą specjalnego pliku .npmrc , który można ustawić na różnych poziomach w zależności od wymagań:

• Poziom projektu: w katalogu głównym kodu projektu wraz z jego plikiem package.json , zazwyczaj path/to/project/.npmrc
• Poziom użytkownika: katalog, który konfiguruje konto konkretnego użytkownika, zwykle ~/.npmrc
• Poziom globalny: katalog, w którym npm szuka konfiguracji globalnych, zazwyczaj $PREFIX/etc/npmrc
• Wbudowany poziom: bądź ostrożny. Ta konfiguracja jest nie tylko globalna, ale jest również częścią kodu źródłowego npm, a najlepsze praktyki zalecają (w rzeczywistości wymagają), abyśmy nie zmieniali kodu, za którego utrzymanie nie jesteśmy odpowiedzialni. Zazwyczaj można go znaleźć w /path/to/npm/npmrc .

Ustawienia konfiguracji w pliku .npmrc można modyfikować i utrwalać za pomocą interfejsu wiersza polecenia, uruchamiając polecenie w tym formacie: npm config set <key> <value> .

Na przykład można uruchomić npm config set access public , aby trwale upublicznić konfigurację publikowania pakietu objętego zakresem (prywatnego).

Domyślnie to polecenie utrwali konfigurację lokalnie (konfigurację na poziomie użytkownika, jak opisano powyżej), ale możesz dodać -g , aby zachować ją globalnie.

Gdy konfiguracja utrwalona musi nastąpić na poziomie projektu lub na poziomie wbudowanym, plik .npmrc należy zmodyfikować za pomocą edytora tekstu.

Konfiguracja przez package.json

Na koniec konfigurację można ustawić z pliku package.json . Jest to jednak rzadko używane (i powinno być używane tylko wtedy, gdy jest to jawnie wymagane), ponieważ plik .npmrc na poziomie projektu jest konwencjonalnie preferowanym miejscem do ustawiania konfiguracji pakietu.

Wybitne ustawienia konfiguracyjne

• access : Jak omówiono powyżej, służy do ustawiania uprawnień.

• always-auth : Ważne jest, aby pamiętać, że to ustawienie ma domyślną wartość false. Gdy jest ustawiony na true, npm zawsze będzie wymagał uwierzytelniania podczas kontaktowania się z rejestrem.

• ca : Domyślnie jest to urząd certyfikacji npm (CA). Można go zmienić na null, aby umożliwić dostęp tylko znanym rejestratorom, lub do określonego certyfikatu CA, aby przyznać dostęp tylko do tego konkretnego. To ustawienie, wraz z cafile , cert i strict-ssl , jest rzadko używane, ale mówi o aspekcie bezpieczeństwa i niezawodności npm, zapewniając spokój ducha, wiedząc, że instalowany pakiet pochodzi ze źródła, którego oczekujesz.

• color : domyślnie ustawiona na true, dająca przerwę od standardowej ponurości terminala przez pokolorowanie stdout , które jest dozwolone przez deskryptory plików tty. Jeśli ustawione na false terminal pozostaje nudny. Gdy jest ustawiony na always , zawsze wyświetla w kolorze.

• depth : to ustawienie pozwala na szczegółową kontrolę nad tym, co widzisz za pomocą poleceń rekurencyjnych, takich jak ls i outdated , poprzez przypisanie, jak głęboko są wykonywane. Wartość 0 oceni tylko pierwszy poziom zależności, podczas gdy nieskończoność (wartość domyślna) spowoduje, że zostaną ocenione wszystkie poziomy zależności. Wyjątkiem od tej reguły jest używanie go z outdated ; w takim przypadku nieskończoność jest interpretowana jako 0, aby zapewnić bardziej odpowiednie dane wyjściowe.

• dev : domyślnie jest to ustawione na false, ale gdy jest ustawione na true (podczas wykonywania npm install ), wszystkie zależności programistyczne w pliku package.json zostaną zainstalowane wraz z normalnymi zależnościami.

• dry-run : Gdy to ustawienie jest ustawione na true, npm nie dokona żadnych zmian w twoim pakiecie, ale zamiast tego powie ci, co by zrobił. Może to być bardzo przydatne podczas uruchamiania niektórych poleceń, takich jak dedupe lub update .

  

• git-tag-version : domyślnie jest ustawiona na true. To ustawienie oznacza wersję w git podczas uruchamiania polecenia npm version . Jeśli używasz npm jako menedżera pakietów dla dużego projektu, który ma otagowane wersje w git, możesz zaoszczędzić czas i pamiętać o aktualizacji pliku package.json za Ciebie.

• loglevel : domyślnie jest to ustawione na warn , które wyświetla dane wyjściowe błędu i ostrzeżenia podczas uruchamiania poleceń npm. Inne ustawienia obejmują silent , który nie zapewnia żadnych danych wyjściowych; error , który tylko rejestruje błędy na wyjściu; http , który informuje tylko o błędach żądań http; info , aby uzyskać informacje wyjściowe); verbose , który rejestruje prawie wszystko; i silly , co, jak sama nazwa wskazuje, daje głupią ilość wyjścia, a potem trochę.

• production : Gdy ta wartość jest ustawiona na true, npm działa odpowiednio i uruchamia wszystkie polecenia w trybie produkcyjnym. Oznacza to, że programowanie lub opcjonalne zależności nie zostaną zainstalowane, ani żadne zadania związane z programowaniem nie zostaną wykonane.

• rollback : Po ustawieniu na true wszystkie nieudane instalacje są usuwane. Jest to przydatne, gdy instalacja zależności nie powiedzie się. W zależności od poziomu rejestrowania powinieneś być w stanie zobaczyć, które instalacje nie powiodły się, zanotować je i uruchomić polecenie npm install z opcją wycofania ustawioną na true. Następnie za pomocą notatek i instalacji na sucho (jak opisano powyżej) możesz debugować problem.

• 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` doda lodash do twoich zależności.

• save-dev : Podobnie jak w przypadku opcji zapisywania konfiguracji, dodaj --save-dev podczas instalowania pakietu, a następnie zostanie on dodany do opcji devDependencies w pliku package.json .

• save-optional : Podobnie jak w przypadku opcji zapisywania konfiguracji, dodaj --save-optional podczas instalowania pakietu, a następnie zostanie dodany do opcji OptionalDependencies w pliku package.json .

• save-exact : podczas instalowania pakietów opcje save , save-dev i save-optional modyfikują plik package.json , wstawiając zainstalowany pakiet do odpowiedniej właściwości za pomocą operatora zakresu semver. Podczas wywoływania ustawienia konfiguracji „save-exact” z wartością true, w połączeniu z jednym z powyższych ustawień, używany jest określony numer wersji, ignorując zakres semver.

• save-prefix : Ustawia operator zakresu semver podczas używania save , save-dev lub save-optional . Wartość domyślna to ^ , co pozwala na drobne uaktualnienia pakietów podczas instalacji. Można to ustawić na dowolny poprawny operator zakresu semver z przedrostkiem.

• tag-version-prefix : konwencjonalną wartością domyślną jest v , określająca, co jest dodawane do wersji tagu git podczas uruchamiania npm version .

Aktualizowanie npm Korzystanie z npm

Możesz również użyć npm do aktualizacji.

Po prostu uruchom npm install -g npm@latest , a npm zostanie zaktualizowany do najnowszej stabilnej wersji. Należy zauważyć, że każda wersja Node.js jest dostarczana z konkretną wersją npm iz mojego doświadczenia wynika, że ​​nie powinieneś zbytnio zawracać sobie głowy tym parowaniem.

Pod koniec dnia radzę trzymać się parowania zgodnie z przeznaczeniem.

Używając npm jako samodzielnego narzędzia, upewnij się, że rozumiesz konsekwencje korzystania z dowolnej wybranej wersji. Istnieje świetne narzędzie do zarządzania różnymi wersjami Node.js (i co za tym idzie wersjami npm) w tym samym systemie o nazwie nvm.

Plik package.json

Plik package.json jest kluczowym elementem łączącym wszystko razem.

Jest to wymagane do opublikowania pakietu w rejestrze npm i to tam ożywa część zarządzania zależnościami.

Ma dwa wymagane pola, a mianowicie „nazwa” i „wersja”, a razem te właściwości powinny być unikalnym identyfikatorem.

Pole nazwy powinno być zgodne z pewnymi regułami określonymi w dokumentacji npm dotyczącej nazewnictwa, a pole wersji podlega specyfikacjom semver.

Poza tym możesz mieć listę zależności o długości mili i zdefiniować konkretną wersję, która będzie używana dla każdej z nich, używając wersji semver i operatorów zakresu. Oto lista innych godnych uwagi właściwości.

"Główny"

„main” definiuje punkt wejścia do aplikacji, domyślnie ustawiony na index.js . W zależności od konwencji lub twojego frameworka może to być app.js lub main.js . Możesz oczywiście zrobić to, co chcesz.

„skrypty”

To niedoceniana nieruchomość.

Po pierwsze, może służyć do wykonywania czynności przed publikacją.

Po drugie, zapewnia miejsce, w którym można aliasować szereg często używanych poleceń, począwszy od zadań budowania (zdefiniowanych w gulp lub grunt), wyzwalania instalacji innych zależności (np. Bower), uruchamiania serwera programistycznego z pakietem webpack lub uruchamianie zestawu poleceń bash.

„zależności”

Ta właściwość to lista pakietów potrzebnych aplikacji wraz z kompatybilnym numerem serwera. Jest to godna uwagi właściwość, ponieważ można ją modyfikować z terminala podczas instalowania lokalnych pakietów.

Odbywa się to poprzez dodanie --save (lub skrótu -S ) na końcu polecenia npm install .

Gdy to zrobisz, nowo zainstalowane pakiety zostaną dodane do listy zależności w pliku package.json .

Podobnie zależność można również usunąć, dodając --save podczas uruchamiania polecenia npm uninstall .

Ważne jest, aby być świadomym wzorców wersjonowania semver każdej z zależności i ich znaczenia.

Jeśli reguła semver jest zbyt surowa, tracisz nowe funkcje i ulepszenia, natomiast jeśli reguła semver jest zbyt luźna, można zainstalować łamaną wersję pakietu.

Uszkodzona instalacja pakietu może okazać się dość trudna do naprawienia, zwłaszcza gdy używana jest zminimalizowana wersja pakietu.

„Zależności deweloperskie”

Oddzielna od właściwości dependencies właściwość „devDependencies” umożliwia definiowanie zależności, które są używane tylko w fazie rozwoju i nie są wymagane w przypadku kompilacji produkcyjnej (takich jak ESLint, pakiety grunt-contrib i Protractor). Podobnie jak w przypadku zależności, tę właściwość można zmodyfikować z poziomu terminala, dodając --save-dev (lub skrót -D ) na końcu polecenia npm install lub npm uninstall . Ta sama ostrożność dotyczy wersjonowania, jak wspomniano w zależnościach.

"kosz"

Tutaj możesz określić pliki wykonywalne swojego pakietu, takie jak ścieżka do narzędzia CLI. Ta właściwość mówi npm, aby tworzył lokalne lub globalne dowiązania symboliczne do plików wykonywalnych, gdy pakiet jest instalowany.

„konfiguracja”

Jak omówiono wcześniej, tutaj definiujesz ustawienia konfiguracji za pomocą pliku package.json .

"prywatny"

Po ustawieniu na true, npm odmówi opublikowania pakietu.

Nie należy tego mylić z ustawieniem konfiguracji dostępu.

Jest to przydatne ustawienie, gdy masz projekt, który wykorzystuje npm wraz z package.json , ale nie jest przeznaczony do publikowania w rejestrze npm, ani w zakresie, ani w publicznym.

Jeśli twoja intencja się zmieni, po prostu zmień ustawienie na false, a będziesz mógł opublikować swój pakiet.

Właściwości niestandardowe

Plik package.json akceptuje również właściwości niestandardowe, o ile nazwa nie jest już zdefiniowana lub zarezerwowana.

Tworzenie własnego pakietu npm

Ekosystem npm jest wypełniony pakietami pisanymi przez tysiące różnych programistów na całym świecie. Każda rozwiązuje jakiś problem, dostarczając abstrakcji lub przedstawiając implementację czegoś.

Są szanse, że w pewnym momencie Ty też będziesz chciał stworzyć swój własny pakiet do udostępniania.

Najpierw musisz napisać plik package.json z minimalnymi wymaganymi właściwościami „name” i „version”, a następnie właściwość „main”, aby określić punkt wejścia, na przykład index.js.

Napisz swój kod w tym pliku index.js, zaloguj się przy użyciu konta użytkownika npm lub utwórz nowego użytkownika z terminala i możesz opublikować go w rejestrze npm.

Pakiety mogą być publiczne lub prywatne.

Publiczne pakiety można publikować za darmo i każdy może z nich korzystać.

Pakiety prywatne, zwane pakietami z zakresem, mogą być publikowane tylko wtedy, gdy zapłaciłeś użytkownikowi modułów prywatnych i mogą być identyfikowane przez odrębny @username/ , który jest dodany do nazwy pakietu.

Pakiety objęte zakresem można również publikować publicznie, wywołując polecenie publish z --access=public .

Co więcej, jeśli poświęcisz trochę więcej czasu na rozbudowę i ulepszenie bazy kodu swojego pakietu i nadszedł czas na opublikowanie nowej wersji, po prostu zmieniasz wersję (zgodnie z zasadami i konwencją semver) pakietu w package.json plik i wpisz npm publish .

Możesz również użyć interfejsu wiersza polecenia i wywołać npm version <update_type> , gdzie update_type to patch , minor lub major , zgodnie z opisem w semver, a to automatycznie zwiększy numer wersji w pliku package.json .

NPM Organizacje

Ponownie, dokumentacja npm jest doskonała i nie ma sensu po prostu powtarzać ich słów.

To, co można powiedzieć o organizacjach w kontekście npm, to to, że jest to bardzo drobiazgowe, a przy prawidłowym zarządzaniu dużymi zespołami i osobami, pracującymi na pakietach objętych zakresem lub publicznymi pod jedną nazwą, można bardzo dobrze zarządzać i ograniczać.

Choć jest to trudne do opanowania, jest to bardzo satysfakcjonujące.

Potęga npm

Ostatecznie dokumentacja dostarczana przez npm jest obszerna i należy się z nią zapoznać w celu uzyskania szczegółowych informacji, ale ten artykuł zawiera przydatny przegląd zarówno podstawowych, jak i bardziej zaawansowanych, zaangażowanych funkcji, ukazując wspaniałość npm.

Jak ze wszystkimi rzeczami, istnieją silne opinie i można znaleźć wiele wad. Ale jeśli nigdy nie próbowałeś npm (lub węzła, jeśli o to chodzi), zanurkuj i zbadaj to dla siebie. Są szanse, że spodoba ci się bardziej niż myślisz.

Aby uzyskać więcej interesujących artykułów na temat npm, rozważ przeczytanie Używanie Scala.js z npm i Browserify.