Narzędzia JavaScript Full-Stack Web Developera: Konfiguracja

0:00Co więcej, jeżeli teraz uruchomimy sobie polecenia np.

0:02npm bugs, zostaniemy natychmiast przeniesieni do katalogu Issues.

0:06Swoją drogą, jeżeli już jesteśmy w

0:08repozytorium, to chciałbym zwrócić uwagę na jeszcze jedną praktykę, która jest

0:12stosunkowo rzadko stosowana, a jednocześnie odgrywa znaczącą rolę,

0:15szczególnie w momencie, gdy rozwijamy wiele różnych projektów.

0:18Chodzi mianowicie o plik README i uwzględnienie w nim przynajmniej minimum

0:22komentarzy, które pozwolą uruchomić ten projekt.

0:24Oczywiście w niektórych sytuacjach

0:26wystarczy po prostu uruchomić polecenie npm start

0:29natomiast w momencie, gdy potrzebne są

0:30jakieś dodatkowe kroki, to zawsze warto mieć je tutaj pod ręką.

0:34Tymczasem myślę, że możemy tutaj

0:36zainstalować pierwszą paczkę i będzie nią powiedzmy Express.

0:40Po instalacji w naszym projekcie pojawił

0:42się oczywiście katalog node modules oraz plik package.json lock

0:46Zobaczmy więc o co w nim dokładnie chodzi.

0:48Oczywiście na ten moment nie mam wątpliwości, że plik package.json nie jest

0:51Ci nieznany, ale jednocześnie wiem, że na jego temat wiadomo stosunkowo mało.

0:57Przede wszystkim, tak jak powiedziałem w jednej z poprzednich lekcji, jeżeli

1:00otworzymy sobie plik package.json no to widzimy tutaj listę zależności tego projektu.

1:04Jednak w pliku lock mamy zdecydowanie więcej informacji, ponieważ przechowujemy

1:08tutaj również zależności, które są niezbędne do uruchomienia Express.js

1:13Oznacza to, że tworzy nam się tutaj takie drzewo zależności uwzględniające np.

1:17wersje poszczególnych paczek, które

1:19aktualnie tutaj obowiązują w naszym projekcie.

1:22Taki plik naturalnie umieszczamy w naszym repozytorium ze względu na to, że musimy

1:27zadbać o to, aby inne osoby pracujące nad naszym projektem oraz również serwer

1:31produkcyjny miał dostęp do tych samych wersji naszych zależności.

1:35Jednocześnie jest jeden wątek, o którym należy tutaj pamiętać i jest nim

1:39konkretnie sposób określania wersji zależności.

1:42Otóż jeżeli przejrzymy sobie teraz dostępne wersje pakietu Express, to mamy tutaj np.

1:47wersję 4.17.0.

1:49Jeżeli uwzględnimy ją tutaj w naszych zależnościach, no to oczywiście w momencie

1:53skasowania katalogu node-modules oraz pliku lock po instalacji zależności zostanie

1:58wygenerowany plik lock uwzględniający tą konkretnie wersja.

2:02Ale jeżeli w tym momencie chcielibyśmy dokonać aktualizacji i jednocześnie

2:06znajdowałby się tutaj daszek, no to nasz plik Packet.json log zasadniczo się tutaj zmieni.

2:12Mianowicie zwróć uwagę, że pomimo tego, że mamy tutaj zapisaną wersję 4.17.0,

2:17nasza wersja zależności przeskoczyła aż na 4.18.1.

2:22I teraz co ciekawe, to samo mogłoby się wydarzyć na samym początku, w momencie

2:25gdybyśmy nie mieli zarówno pliku lock oraz katalogu node-modules, a

2:29byśmy po prostu w ten sposób zainstalowali nasze zależności.

2:33W tej sytuacji ponownie jeżeli zajrzymy sobie do

2:35tego pliku, okaże się, że faktycznie zainstalowana wersja zależności została

2:40zmieniona w stosunku do tego, co mamy uwzględnione w Package.json.

2:44Oczywiście tutaj wszystko działa

2:45poprawnie, ale brak świadomości tego, że tak może być oznacza potencjalne kłopoty.

2:51Z tego powodu, tak jak powiedziałem,

2:52znacznie lepiej jest stosować albo tylde do tego, aby aktualizować wyłącznie patche

2:57lub też bezpośrednio określać wersję paczki, którą chcemy zainstalować.

3:01Tym bardziej, że jeżeli nawet uwzględnili byśmy tutaj zapis bezpośredni, to i tak w

3:06celu aktualizacji naszego projektu moglibyśmy uruchomić polecenie npm outdated.

3:11W ten sposób zostaną wyświetlone wszystkie zależności naszego projektu wraz z

3:15informacją o tym, w przypadku których pojawiły się nowe wersje.

3:19No i tutaj dopiero w momencie, gdybyśmy chcieli rzeczywiście zaktualizować

3:22jakąś paczkę, moglibyśmy wykorzystać polecenie npm install express, a następnie

3:26po @ podać konkretną wersję, którą chcemy zainstalować.

3:30W rezultacie, jeżeli przejdziemy sobie teraz do pliku package.json

3:34no to akurat tutaj wersja co prawda

3:35została zaktualizowana, ale dalej mamy w tym miejscu ^.

3:39Taka sytuacja nie miałaby miejsca w

3:41momencie, gdyby wcześniej nie było go tutaj.

3:43Jeżeli jednak chcielibyśmy domyślnie

3:45instalować paczki o określonej wersji, moglibyśmy uruchomić polecenie npm config

3:50set, a następnie opcję save-exact ustawić na true.

3:54Coś takiego zmieni nasze domyślne

3:55ustawienia i od tej chwili gdy będziemy instalować paczki o określonej wersji

4:00no to w pliku package.json tego ^ ani ~ po prostu nie będzie.

4:05Myślę, że jest to dość dobre ustawienie,

4:07które domyślnie nie jest aktywne, a rzeczywiście może pomóc.

4:10I tutaj jeżeli chodzi jeszcze o polecenie

4:12npm config to mamy tutaj możliwość ustawienia domyślnego adresu email oraz w

4:17przypadku właściwości name naszego imienia i nazwiska.

4:20W momencie gdy to zrobimy, za każdym razem, gdy będziemy tworzyć nowy Package.json

4:25z pomocą npm init, te dane zostaną w tym miejscu uwzględnione.

4:29Jeżeli z jakiegoś powodu interesowałoby

4:31Cię to, gdzie te informacje są przechowywane, no to mówimy tutaj o pliku

4:35znajdującym się w katalogu domowym o nazwie npmrc.

4:39Wewnątrz niego przechowywane są właśnie wszystkie ustawienia domyślne

4:42i co ciekawe, taki plik npmrc możesz utworzyć również w katalogu

4:46bieżącego projektu i tym samym nie będą one obowiązywały globalnie w Twoim

4:51systemie, tylko w ramach właśnie tego konkretnego projektu.

4:54I swoją drogą, jak już byliśmy tutaj w

4:56katalogu domowym, no to zwróć uwagę, że oprócz pliku npmrc

5:01mamy tu jeszcze katalog .npm, który stanowi nic innego jak pamięć podręczną npm.

5:06W niektórych sytuacjach może okazać się, że będziesz potrzebować tam zajrzeć.

5:10Tymczasem ostatnią informacją jaką mam dla Ciebie jest wykorzystanie polecenia npx.

5:16I swoją drogą od razu mamy tutaj przykład

5:18jakiegoś gista, które możemy wykonać bezpośrednio właśnie z pomocą npx.

5:23Przykładowo jeżeli teraz wcisnę Enter, mamy tutaj informację, która została tutaj

5:27wykonana z pomocą Console Loga znajdującego się w tym gist.

5:31I co więcej, coś takiego jest tutaj możliwe ze względu na to, że npx

5:35kontaktuje się bezpośrednio z rejestrem npm.

5:38Oznacza to, że za jego pomocą możemy odwoływać się do paczek, które fizycznie

5:42nie są zainstalowane jako globalne pakiety npm na naszym komputerze.

5:46Przykładem może być chociażby Vue CLI, w przypadku którego nawet jasno mamy powiedziane,

5:51że CLI dostępne jest albo w katalogu node-modules, albo też jesteśmy w stanie

5:56wykorzystać tutaj npx do tego, aby wykonywać tutaj polecenia bez konieczności

6:01np. posiadania CLI zainstalowanego na naszym komputerze.

6:04Dodatkowo, analogicznie jak w przypadku

6:07instalacji, jesteśmy w stanie tutaj podać wersję paczki, do której chcemy się

6:10odwołać i tym samym jeszcze bardziej ułatwić sobie cały proces.

6:14Jeżeli chodzi o npx, według mnie najlepiej

6:17sprawdza się właśnie w przypadku, gdy mamy do czynienia z różnego rodzaju CLI.

6:21Tymczasem jeżeli chodzi o tą lekcja to by było na tyle.

6:25Pamiętaj proszę, aby uwzględnić to jak zachowują się wersje projektów w przypadku

6:29pliku package-lock oraz dlaczego jest on tak istotny.

6:32Jednocześnie dbaj też proszę o to jak wygląda Twój plik Package.json

6:36ze względu na to, że to w jaki sposób będziesz nim zarządzać będzie docenione

6:40zarówno przez inne osoby w Twoim zespole, jaki również Ciebie w przyszłości.

6:44Po prostu wracając kiedyś do tego

6:46projektu, będziesz w stanie się w nim lepiej odnaleźć.

6:49No a tymczasem nie pozostaje mi nic

6:50innego, jak zaprosić Cię do kolejnej lekcji.