React: Konfiguracja Husky i Lint-staged

16.8.x

0:00Cześć, w poprzedniej lekcji udało nam się skonfigurować prettier'a a jeszcze wcześniej ESlinta,

0:04a to wszystko po to, żeby zagwarantować, że nasz kod będzie jak najlepiej

0:08uporządkowany, że nie pojawi się w nim żaden nieproszony błąd,

0:12a przynajmniej taki, który wychwyci jedno albo drugie narzędzie. Jeszcze

0:16teraz zanim przejdziemy do dalszej części naszego kursu, musimy

0:21zrobić jedną bardzo ważną rzecz. Jak widzisz, ja na dole tutaj mam terminal

0:25i mam różne branch'e commit'uje ten cały ten kod w zależności od lekcji,

0:29w której się znajdujemy, zakładam, że ty również własny kod będziesz commit'ować

0:33gdzieś, zakładam, że masz własne repozytorium i na przykład wypchniesz te zmiany

0:37później github'a, na bitbucked czy gdziekolwiek indziej i rzeczy,

0:42której chcemy na pewno uniknąć to przypadkowe zacommit'owanie błędnego kodu, czyli

0:46takiego którego w jakiś sposób ESlint albo prettier nie wychwycił i

0:50nie naprawiły w locie, więc żeby tego uniknąć, dodamy

0:54jeszcze dwa narzędzia nazywają się husky i lint-staged i dzięki

0:58nim będziemy mieć taką pewność, że zanim zrobimy jakikolwiek commit,

1:02uruchomi się tak zwany hook, który sprawdzi czy nasz kod, aby

1:06na pewno nie zawiera żadnych dziwnych błędów, więc teraz

1:11do naszego projektu dodamy sobie dwie paczki. Zainstalujemy

1:16je tutaj npm install, jak zwykle są to paczki dla deweloperów, czyli flaga

1:21D husky, jak ktoś lubi psy to łatwo zapamięta i lint-staged,

1:26czekam aż się zainstaluje, a tym

1:31czasie możemy sobie odpalić dokumentację husky'ego i przeciwieństwie

1:41do poprzednich pluginów, które dodawaliśmy konfiguracja husky'ego jest naprawdę

1:45bajecznie prosta, jedyne co musimy zrobić to w naszym package json dodać

1:49pole husky, to sobie skopiujemy, odpaliłem

1:55package json, gdzieś tutaj na dole husky, jak

2:02widzisz husky oferuje tak zwane hooks'y, mamy różne rodzaje tych

2:06hooks'ów, całą listę znajdziesz oczywiście w dokumentacji, natomiast

2:10my potrzebujemy tylko jednego, jest precommit, czyli coś

2:14co dzieje się przed za commit'owaniem kodu, czyli zanim zacommit'ujemy kod,

2:18odpali się husky. Sprawdzi czy wszystko jest okej, jak

2:22nie jest okej, to commit się nie wykona, pokaże nam jakie mamy błędy i dopiero

2:26jak je naprawimy to pozwoli nam wykonać commit i to co my chcemy zrobić

2:30to wykonać komendę lint-staged i

2:34do tego właśnie będzie nam potrzebna ta druga paczka. Teraz

2:40wpiszemy sobie lint-staged, jak

2:44sobie zjedziemy tutaj na dół, to zobaczymy, że mamy nawet takie gotowe przepisy

2:49na to co możemy zrobić w lint-staged, o tutaj

2:54mamy na przykład z husky, czyli mamy husky hooks

2:58pre-commit, tutaj mamy lint-staged, czyli teraz możemy sobie tutaj dodać

3:02i tutaj wpiszemy

3:09lint-staged, kluczem tego obiektu jest rodzaj

3:13plików, na których będziemy operować i w naszym przypadku będą to wszystkie pliki JavaScript

3:17gwiazdka oznacza wszystkie nazwy i oczywiście kropka

3:21JS to jest rozszerzenie dla plików JavaScript i następnie tutaj w tej

3:25tablicy, po kolei podajemy wszystkie procedury, które mają się wykonać i uwaga one

3:29się wykonują w takiej kolejności w jakiej napiszemy, pierwsza jaką chcemy

3:33wykonać prettier z flagą write. Dodatkowo

3:37chcemy jeszcze podać konfigurację, która

3:42znajduje się w pliku plik prettierrc, następnie

3:47wykonamy ESlint z flagą fix, czyli ESlint spróbuje naprawić

3:51wszystkie błędy, które się pojawiły, a następnie robimy git add. Dlaczego

3:55gitadd? No bo procedura jest taka, najpierw dodajemy nasz kod, czyli

3:59robimy git add, później robimy git commit, nazywamy commit, później

4:04odpala się to. Nasze

4:08narzędzia jeśli zdołają, to naprawiają nasz kot przez prettier'a, naprawiają nasz

4:12kod przez fix'a i następnie ten zmieniony kod

4:17musi zostać dodany, więc jeśli wszystko poszło dobrze, jeśli

4:21udało się automatycznie naprawić te błędy to to musi dojść

4:25do dodania tego dostaje w naszym repozytorium, czyli

4:30do tego commit'a, który stworzyliśmy ten kod na nowo musi zostać dodany, żeby

4:34zmiany poczynione przez nasze pluginy zostały uwzględnione i wtedy dopiero dochodzi

4:38do commit'a. Jeśli natomiast były jakieś błędy to husky nas stopuje

4:43i nic nam się nie uda, musimy poprawić nasze błędy, a dopiero później wykonać

4:47commit. Z taką konfiguracją możemy teraz przetestować czy to

4:51wszystko działa, próbujemy zepsuć nasz plik app js,

4:55z powrotem stworzyłem klasę

4:59zamiast czystej funkcji, jest to błąd w ESlint'cie, którego

5:04sam ESlink na pewno nie naprawi, więc to co się wydarzy to ESlint

5:09powinien wrzucić błędem podczas wykonywania tej komendy lint-staged. Uwaga,

5:16więc dodaje wszystkie zmiany i teraz ja

5:21już dodałem sobie commit 01.5-finish, to jest commit,

5:25który mam dodać na tym branczu, więc ja kolejnego commit'a nie będę dodawał

5:29tylko zrobię amenda natomiast u ciebie prawdopodobnie będzie to wyglądać tak, że

5:33to będzie git commit z jakąś tam wiadomością. W moim

5:38przypadku będzie to git commit amend no

5:42edit, to znaczy, że zmiany, które teraz robimy, dodajemy

5:46do ostatniego commit'a, a nie tworzymy nowego commit'a i nie

5:51dodaję żadnego nowego komunikatu do treści tego commit'a i

5:55teraz uwaga, ciekawe czy husky się wywali,

6:00okej, przeanalizujmy co się wydarzyło

6:04i jak widzisz husky się uruchomił następnie

6:10przeszedł do wykonywania procedury uruchomił prettier'a, prettier ogarnął

6:14wszystko, zobaczył że wszystko jest w porządku. Później przyszedł ESlint, zobaczył

6:18że nie może czegoś naprawić rzucił nam błędem, mówi w jakim

6:22pliku jest błąd i że mamy go sobie sami naprawić, więc

6:28teraz sami go naprawimy, ale za to zepsujemy coś innego,

6:33coś co prettier sam powinien ogarnąć. Okej,

6:42dodajemy nasze zmiany i ja robię dokładnie to samo git commit amend no

6:47edit. Uwaga,

6:51tym razem

6:55wszystko poszło tak jak trzeba commit został dodany, natomiast

7:00jak widzisz nasz plik również został naprawiony, nie ma żadnych błędów, ale

7:05w naszej konfiguracji w naszych plikach istnieje jeszcze jeden mały problem, o którym wcześniej

7:09nie wspominałem i jedną rzecz musimy dodać do konfiguracji ESlinta, mianowicie

7:13chodzi o to, że ESlint i prettier w tych hooks'ach, które skonfigurowaliśmy w package json

7:17sprawdzają wyłącznie te pliki, które dodajemy do commit'a, które zostały zmienione, a przecież

7:22nie wszystkie pliki, które dodawaliśmy do commit'a były zmieniane, na

7:26przykład index js albo app test js i jak widzisz ESlint się

7:30czepia tego, że document is not defined, a przecież document to jest po prostu część

7:34DOM'u i musimy się do tego w jakiś sposób odwołać i przez to, że używamy

7:39czegoś takie jak document albo używamy czegoś takiego it to w sensie

7:43musimy powiedzieć słuchaj ESlint, my będziemy korzystać z określonego środowiska

7:48i musisz pewne rzeczy po prostu tolerować. Dlatego teraz wejdź mi sobie do ESlinta

7:52i mamy takie dwie rzeczy, które musimy ustawić, pierwsze to środowisko, w

7:56którym pracujemy i tutaj przez środowisko mam na myśli środowisko testowe, które

8:00używamy, jest to gest i musimy powiedzieć, że tak

8:05że z jest'a skorzystamy i wtedy on przestanie się czepiać tego it, które

8:09należy właśnie do jest'a. Widzisz, że ten błąd już zniknął, a drugą

8:14rzeczą, którą musimy ustawić to takie zmienne globalne, do których będziemy się

8:18odwoływać i ESlint prostu musi po prostu wiedzieć co z nimi robić, więc tutaj ustawimy

8:22sobie globales i powiemy, że document to jest

8:26zmienna, którą on po prostu ma przepuszczać, ma ją tolerować i teraz sprawdźmy

8:30czy to zadziałało, odpalimy sobie ESlint'a po prostu

8:34z poziomu naszego terminala. Uwzględnimy wszystkie pliki js i faktycznie

8:40żadnego błędu nie ma. Natomiast jeśli usuniemy to co pisaliśmy przed chwilą to

8:46zobaczymy, że mamy błędy właśnie dotyczące jest'a i document'u, więc

8:50przywracamy te zmiany i w ten sposób nasze ESlint

8:54przestanie się czepiać tych zmiennych i środowiska, którego będziemy

8:58używać, więc nasza konfiguracja dobiegła końca. Mamy

9:03całkiem fajnie ustawiony projekt, kod jest automatycznie formatowany,

9:07naprawiany, także wszystko idzie po naszej myśli, a w następnej

9:12lekcji już zaczynamy konfigurację nowych narzędzi, ale związanych

9:16już typowo z development'em i obiecuję ci, że będzie to mega ekscytująca przygoda. Do

9:20zobaczenia w następnej lekcji.