Narzędzia JavaScript Full-Stack Web Developera: Manifest projektu

0:00Myślę, że taką jedną z lepszych technik,

0:03które można wykorzystywać od czasu do czasu jest przeglądanie npm od GitHuba w

0:07poszukiwaniu najbardziej docenianych projektów.

0:10W związku z tym, że ich kod źródłowy jest

0:13otwarty, możemy pooglądać sobie różnego rodzaju dobre techniki dotyczące albo

0:17konfiguracji samego projektu, albo w tym przypadku przyjrzymy się plikowi package.json

0:22I właśnie to ten plik będzie bohaterem tej lekcji,

0:25ze względu na to, że stanowi on serce aplikacji tworzonej z pomocą JavaScriptu.

0:30Pomimo tego, że jego obecność może być utożsamiana bezpośrednio z

0:34pakietami NPM, tak jednocześnie w naszym projekcie również musimy go posiadać ze

0:39względu na jego dodatkowe funkcje, o których zaraz powiem.

0:43W tym momencie zakładam, że jego podstawowa struktura jest Ci doskonale

0:46znana i zresztą nie ma co tu tłumaczyć ze względu na to, że ewentualnie może nas

0:50interesować wersja projektu, ponieważ zwykle gdy rozwijamy je wyłącznie na nasze

0:54potrzeby, to rzadko kiedy ktokolwiek zwraca na nią uwagę.

0:58W praktyce jednak, jeżeli chodzi o

1:00zależności projektu, jak również posiadają swoje wersje, sytuacja jest tutaj nieco

1:05bardziej złożona i będziemy sobie o niej mówić w jednej z kolejnych lekcji.

1:08Tymczasem całkiem użyteczny jest tutaj jeszcze link do repozytorium,

1:12ze względu na to, że jeżeli informacja o nim się tutaj znajduje, to możemy takim

1:16oto poleceniem przenieść się bezpośrednio do repozytorium tego projektu.

1:21Jednocześnie to samo możemy zrobić poprzez słowo kluczowe bugs.

1:25W ten sposób zostaniemy przeniesieni

1:26również do repozytorium, ale do zakładki Issues.

1:30Na podstawie mojego doświadczenia mogę powiedzieć, że zaglądanie w zakładkę Issues

1:33jest ponownie czymś, co spotykam dość rzadko u innych osób, a jednocześnie dla

1:38mnie zarówno otwarte, jak i zamknięte tickety są często źródłem wiedzy na temat

1:43problemów, które spotykam z różnego rodzaju pakietami.

1:46Po prostu zamiast wyszukiwać jakiś problem

1:48w Googlu, wystarczy wyszukać go po słowie kluczowym w tym miejscu.

1:51W ten sposób możemy zostać przeniesieni do wątku, gdzie ktoś bardzo dokładnie opisze

1:56problem, który spotykamy i co więcej albo od razu zaproponuje rozwiązanie, albo

2:01gdzieś w komentarzach ktoś nas na nie nakieruje.

2:04Teraz wróćmy jeszcze na chwilę do Package.json.

2:06Oczywiście tutaj są jeszcze pola, które możesz brać szczególnie

2:09pod uwagę, gdy tworzysz paczkę, którą chcesz udostępniać publicznie,

2:13natomiast na potrzeby wewnętrznie

2:14tworzonych projektów raczej nie odgrywają one większej roli.

2:17Jednocześnie jest tutaj jeszcze właściwość

2:19private, którą możesz ustawić na true, aby nawet w sytuacji, gdy ktoś przypadkowo

2:24będzie próbować opublikować swoją paczkę, to taka akcja zostanie tutaj zablokowana.

2:29Poniżej mamy tutaj sekcję scripts.

2:31I co do niej, to myślę, że jesteś w stanie

2:33ją wykorzystywać i zresztą z całą pewnością już to robisz,

2:37natomiast jednocześnie w kontekście tworzenia własnych skryptów i ich

2:40organizacji jest kilka istotnych wątków i z tego powodu również będziemy sobie o nich

2:45jeszcze rozmawiać w jednej z kolejnych lekcji.

2:47To co musisz jednak wiedzieć na tym

2:49etapie, to fakt, aby po prostu tworzyć te skrypty.

2:52Po prostu bardzo często spotykam się z projektami,

2:55czasem również zdarzało mi się takie

2:57tworzyć samodzielnie, w przypadku których nie było zdefiniowanych żadnych skryptów,

3:01ponieważ i tak można było wykonywać je ręcznie.

3:03Rzecz w tym, że wracając do projektu po

3:05kilku miesiącach bądź nawet kilku latach jego uruchomienie przestaje być oczywiste

3:10w szczególności jeżeli mamy jakiś złożony proces budowania tego projektu.

3:14W związku z tym bardzo dobrą praktyką,

3:16której należy się tutaj trzymać jest po prostu zapisywanie skryptów od razu, gdy

3:20je tworzymy i po prostu nie odkładanie na później.

3:23Jeżeli chodzi o pozostałe elementy, to

3:25czasem zdarzają się jakieś ustawienia, w tym przypadku dotyczące Prettiera, aczkolwiek

3:29ja osobiście z takimi jeszcze się nie spotkałem,

3:32no i oczywiście mamy zależności projektu, czyli w zasadzie wszystko co musi być

3:36doinstalowane do naszego projektu aby był uruchomiony poprawnie.

3:39I tutaj zwróć uwagę na pewien szczegół.

3:42Mianowicie wszystkie wersje zależności, które są tutaj opisane i

3:45wyjątkiem jest ta tutaj, są zainstalowane poprzez podanie ich konkretnej wersji.

3:50W niektórych sytuacjach zdarza się tak, że

3:52przed zapisem wersji mamy ^ bądź bądź symbol ~.

3:56Oznacza to, że w momencie instalacji

3:58danego pakietu możliwe będzie zwiększenie w tym przypadku wersji patcha, czyli tej

4:03ostatniej cyfry, bądź też w przypadku gdyby była tutaj tylda to w momencie instalacji tego

4:08projektu możliwe byłoby zaktualizowanie nawet wersji minor, która być może

4:12wprowadza nawet bugi, bądź nawet jeżeli to nie są bugi, to po prostu jakieś dodatkowe

4:17elementy przestają z jakiegoś powodu współpracować z naszym projektem.

4:20Oczywiście teoretycznie tak się nie powinno wydarzyć, ale zapisywanie wersji

4:24dokładnie takiej jakiej oczekujemy, żeby się zainstalowała jest po prostu znacznie

4:29bezpieczniejsze i daje nam większą kontrolę nad naszym projektem.

4:32Jednocześnie musisz pamiętać o tym, że

4:34nawet jeżeli instalujesz jakiś pakiet i on sam zależy od innych, to oczywiście ich

4:38twórcy nie muszą przestrzegać tej zasady i może się czasem okazać, że po prostu

4:42dodatkowe stopnie zależności zostały gdzieś zaktualizowane po drodze.

4:47Jak sobie z tym poradzić będziemy sobie

4:48jeszcze mówić. No i tutaj jeszcze na dole mamy jeszcze dość

4:52ważny element w postaci określenia, na jakiej wersji Node.js działa dana paczka.

4:57W tym przypadku jest to wersja przynajmniej 12.9.0

5:00ale ważniejszą informacją jest tutaj to, że

5:02jeżeli spróbujemy uruchomić ten projekt na wersji mniejszej niż 12.9.0, to zostaniemy

5:08o tym jasno poinformowani. W momencie, gdyby tej informacji nie było

5:11zostaniemy zasypani błędami i będziemy

5:14musieli tutaj na piechotę dojść do źródła problemu.

5:16Idąc dalej mamy tutaj jeszcze dodatkowe

5:19elementy konfiguracji i też specyficzne elementy dla tej konkretnej paczki

5:23w związku z tym dla nas nie ma już tutaj raczej nic ciekawego.

5:27Zatem podsumowując temat pliku Package.json warto upewnić się, że zawiera on

5:31przynajmniej minimum informacji, które umożliwią nam uruchomienie tego projektu.

5:36Tymi informacjami są przede wszystkim jego nazwa oraz wersja

5:40w momencie, gdy publikujemy paczkę oraz

5:42oczywiście skrypty umożliwiające uruchomienie projektu

5:45no i oczywiście lista zależności.

5:47No i tutaj jeżeli chodzi o tą główną listę zależności oraz listę zależności

5:51deweloperskich domyślam się, że wiesz doskonale o co tutaj chodzi, ale w razie

5:55potrzeby po prostu paczki developerskiej nie będą instalowane

5:58w momencie gdy wykorzystamy polecenie npm install z flagą production.

6:03Myślę, że na tym etapie w temacie wprowadzenia do manifestu projektu, czyli

6:07dokładnie tego pliku myślę, że to byłoby już na tyle.

6:10W związku z tym dziękuję Ci za uwagę i zapraszam do kolejnych materiałów.