Systemy zarządzania pakietami istnieją już od bardzo dawna. Pomagają użytkownikom systemów w automatyzacji instalacji pakietów oprogramowania, a także ich konfiguracji, aktualizacji i innych operacji związanych z zarządzaniem nimi. Możemy je spotkać pracując z systemami operacyjnymi czy różnymi językami programowania.

Świat Javascript też ma swojego menadżera pakietów i jest nim npm. Pierwsze wydanie tego systemu zostało opublikowane na początku 2010 roku. Od tamtego czasu opublikowano już kilka kolejnych wersji. W sieci spotkałem się z informacją, że publicznych repozytoriów w npm’ie jest blisko 500 000. Czy to jest dokładna informacja? Trudno powiedzieć, ale na pewno jest ich bardzo dużo.

Po co nam npm?

Jako programista niejednokrotnie spotykam się z problemem dostępności niektórych narzędzi lub bibliotek, z których chciałbym skorzystać w swoich projektach. Prawda jest też taka, że czasami nie wiedziałbym, gdzie szukać dostępnych na rynku, już napisanych i sprawdzonych bibliotek. Menadżer pakietów jakim jest npm na pewno rozwiązuje te problemy. Istnieje nawet duże prawdopodobieństwo, że jeżeli nie znajdę czegoś w repozytoriach npm’a to raczej nigdzie indziej tego nie znajdę.

Dzisiaj w npm’ie znajdziemy również narzędzia CLI (ang. Command Line Interface), które pomogą nam rozwijać swoje projekty w oparciu o frameworki, takie jak Angular czy środowisko React. npm zdecydowanie przyspiesza pracę, a poprzez zestaw oferowanych narzędzi bardzo ułatwia zarządzania pakietami danych, które wykorzystujemy w swoich projektach.

npm … - i co dalej?

Praca z npm’em to przede wszystkim praca z linią poleceń. npm dostarczany jest domyślnie razem z Node.js. Zatem instalując Node.js domyślnie zainstaluje się nam npm. Zainicjowanie projektu, wykorzystującego npm’a sprowadza się do przygotowania pliku konfiguracyjnego package.json albo do uruchomienia polecenia npm init. Dodanie flagi -y do polecenia inicjującego, odpowie na wszystkie pytania kreatora na „tak”.

Instalacja pakietów odbywa się za pomocą polecenia npm install <nazwa pakietu>. npm instaluje nam paczki na 2 sposoby. Globalnie (za pomocą flagi -g lub --global), wówczas są one dostępne w ramach całego naszego środowiska oraz lokalnie, jeśli chcemy wykorzystywać pakiety tylko w ramach naszego projektu. Domyślnie pakiety instalowane są lokalnie w zbiorze dependencies.

Wszystkie pakiety lokalne instalowane są do katalogu node_modules, ale o tym troszkę później.

Lokalnie na dwa sposoby

Lokalnie mamy do dyspozycji dwa zbiory pakietów, do których możemy instalować: wspomniane wcześniej dependencies (do polecenia instalacyjnego dodając flagę: -S lub --save) oraz devDependencies (dodając flagę: -D lub --save-dev). devDependencies to lista pakietów, które zostaną zainstalowane w czasie trwania developmentu. Jeżeli zmienna środowiskowa NODE_ENV jest ustawiona na production lub podczas instalacji dodamy flagę --production zainstalowane zostaną tylko pakiety ze zbioru dependencies. Warto to wiedzieć i rozumieć różnicę. Szczególnie jeśli planujemy kiedyś opublikować naszą aplikację i nie chcemy, żeby zawierała w sobie wszystko, co było wykorzystywane w czasie procesu programowania.

Co instaluje npm?

Wokół tego co instaluje npm powstało już wiele dowcipów. Niejednokrotnie możesz się spotkać z porównaniem katalogu node_modules do czarnej dziury. Oczywiście czarna dziura jest nic nie znaczącą dziureczką przy potędze katalogu instalacyjnego.

Dlaczego tak się dzieje?

npm opiera się na zależnościach pomiędzy poszczególnymi pakietami. Bardzo często jest tak, że do przygotowania jednego pakietu zostały wykorzystane 3 inne. Instalując jakikolwiek pakiet, instalujemy również jego zależności - co czasami może prowadzić do paradoksów, jak ten gdzie jeden pakiet, właściwie nic konkretnego nie robiący, jest instalowany kilkanaście tysięcy razy tygodniowo, bo jest zależnością jakiegoś często wykorzystywanego narzędzia. Ot paradoks… :)

W katalogu node_modules znajdziemy zatem wszystkie zainstalowane przez nas pakiety, ale także wszystkie ich zależności i ich zależności - podzielone na podkatalogi. Sporo tego.

Oprócz tego w katalogu node_modules mamy podkatalog .bin, gdzie znajdziemy wszystkie wykonywalne pliki zainstalowanych przez nas pakietów. Jest to przydatne, gdy chcemy uruchomić jakiś zainstalowany lokalnie pakiet z pominięciem npm scripts. Uruchomienie takiego pakietu mogłoby wyglądać następująco: ./node_modules/.bin/<nazwa pakietu>.

npx

Od pewnego czasu w npm mamy dostępne polecenie npx, które pozwala nam uruchomić pakiet, który nie został zainstalowany. Po uruchomieniu polecenia npx <nazwa pakietu> w pierwszej kolejności npm sprawdza czy pakiet został zainstalowany wcześniej (katalog .bin) lub czy znajduje się w głównym cache’u. Jeśli pakiet nie zostanie tam znaleziony, dopiero wówczas npm zainstaluje i dopiero wtedy uruchomi wywoływany pakiet.

package-lock.json

Co to za plik? To plik, który generuje się podczas pierwszego uruchomienia polecenia npm install. Każde kolejne wywołanie tego polecenia zaktualizuje plik package-lock.json. Plik ten zawiera informacje o wszystkich zainstalowanych zależnościach i ich wersjach. Przyda się to podczas pracy w zespole, aby zapewnić, że wszyscy pracujemy na tych samych wersjach pakietów. Wyobraź sobie sytuację, gdy pracujemy nad jednym projektem mając różne wersje kluczowych pakietów. W różnych wersjach mogą znajdować się różne metody: mogły zostać usunięte lub dodane w zależności od wersji pakietu. Łatwo wyobrazić sobie problemy, które może to generować.

npm ci

Jeśli w naszym projekcie znajduje się już plik package-lock.json, pamiętajmy, żeby nie instalować pakietów za pomocą npm install. Spowoduje to, że nie wykorzystamy cennych informacji zawartych w pliku lock. Chcąc mieć te same wersje co reszta zespołu instalujmy pakiety za pomocą npm ci.

O wiele, wiele więcej

Kilka powyższych słów to tylko wstęp do tajemnic, które skrywa przed nami npm. Można bardzo dużo napisać o przygotowywaniu repozytoriów, wykorzystywaniu scripts . Myślę, że omówienie samego pliku konfiguracyjnego zajęłoby nam sporo czasu. Dlatego temat pozostawiam otwarty. Obiecuję, że wrócę do niego w najbliższej przyszłości.

Podsumowanie

npm zmienił świat Javascriptu, pomimo że nie jest jedynym menadżerem pakietów (warto wspomnieć również o wydanym w 2012 roku Bower’ze). W moim odczuciu świat Open Source’u jest taki, jakim go znamy w dużej mierze dzięki Isaacowi Schlueterowi, który zainicjował projekt npm’a. Warto poznać dobrze npm’a, tak jak warto dobrze znać Git’a - niewątpliwie jest to jedno z podstawowych narzędzi w rękach współczesnego programisty Javascript.