Jak zabezpieczyć projekt przed przypadkowymi błędami przy użyciu narzędzi ESLint, Prettier i Husky

Każdy programista, niezależnie od poziomu zaawansowania i lat doświadczenia, może mieć gorszy dzień i przez przypadek wprowadzić zmiany, które powodować będą bugi lub po prostu nie będą wpisywały się w dobre praktyki wytwarzania kodu. Na szczęście jest kilka sposobów, dzięki którym możemy zabezpieczyć nasz JS-owy projekt przed takimi przypadkami. 

Jakub Krymarys

Jakub Krymarys. W IT aktywny zawodowo od 4 lat. Obecnie związany z STX Next, gdzie realizuje się jako JavaScript Developer ze specjalizacją w React.js. Miłośnik nowinek ze świata IT oraz wszelkich technologicznych gadżetów. Uwielbia optymalizować swoją pracę. 

 


Zakładam, że pierwszą rzeczą jaka przychodzi wam na myśl są różnego rodzaju testy. Oczywiście są one jak najbardziej dobrą metodą, ale w tym artykule zajmiemy się czymś innym. Zamiast skupiać się na testowaniu funkcjonalności aplikacji, skupimy się na samym kodzie. Wykorzystamy do tego:

  • ESlint – analizuje kod JS, aby znaleźć potencjalne błędy i złe praktyki,
  • Prettier – formatuje kod zgodnie z przyjętym standardem,
  • Husky – pozwala na integrację z Git Hookami, co umożliwia zautomatyzowanie dwóch powyższych narzędzi.

Wszystkie te narzędzia dobrze współpracują z każdym projektem, który bazuje na Node.js. Z uwagi na to, że chciałbym podać też konkretne przykłady configów, te będą omówione na przykładzie “czystego” projektu React.js stworzonego przy pomocy Create React App (CRA).

ESlint – analiza kodu

Zacznijmy od ESlint. Jest to tzw linter, czyli narzędzie, które poddaje JavaScriptowy kod statycznej analizie w celu znalezienia wszelkich potencjalnych problemów. Na każdy z nich może on zareagować na dwa różne sposoby – albo oznaczyć go jako warning (i wyświetlać w konsoli stosowny komunikat), albo jako error (w tym przypadku oprócz komunikatu dodatkowo kompilacja kodu zakończy się błędem).

Jeśli pracowaliście z Reactem, to pewnie widzieliście już niejeden warning lub błąd w konsoli przeglądarki. Część z nich to właśnie efekt działania ESLint. Jest on zintegrowany z aplikacją, którą tworzymy za pomocą CRA. Posiada on tam jednak bardzo minimalistyczną konfigurację.  

Tak wygląda bazowy config ESLinta w  pliku package.json aplikacji React.js stworzonej za pomocą CRA:

Jeżeli jednak z jakiegoś powodu nie macie ESLint w projekcie to można go łatwo dodać za pomocą komendy npm install eslint –save-dev  (https://eslint.org/docs/user-guide/getting-started).

Aby linter był prawdziwym “lifesaverem” naszego projektu, musimy tę bazową konfigurację nieco rozszerzyć. Domyślnie posiada ona tylko zestaw podstawowych zasad specyficznych dla samego Reacta, nie sprawdza natomiast samej składni JS-owej.

Proponuję zacząć od konfiguracji zalecanej przez zespół ESLint –  „eslint:recommended”. Co dokładnie znajduje się w tym zestawie, można zobaczyć w https://eslint.org/docs/rules/).

Jak rozszerzyć konfigurację ESLint? 

Konfigurację lintera możemy rozszerzyć na dwa sposoby – poprzez użycie odpowiedniego pola eslintConfig w package.json lub poprzez stworzenie specjalnego pliku konfiguracyjnego w głównym folderze projektu – .eslintrc. Obydwa działają równie dobrze, jednak ja, jako fan rozbijania wszystkiego na jak najmniejsze fragmenty, polecam wydzielić config do nowego pliku.

Pamiętajcie jednak, że gdy stworzycie konfigurację w osobnym pliku, należy usunąć pole eslintConfig z package.json.

Plik konfiguracyjny .eslintrc składa się z kilku sekcji:

Nasza podstawowa konfiguracja powinna wyglądać więc mniej więcej tak:

Jest to dobry punkt wyjścia do porządnego i świadomego używania lintera. Możecie jednak zmienić tę konfigurację (korzystając z oficjalnej dokumentacji) lub po prostu wprowadzić swoje modyfikacje zasad (również dobrze opisane w dokumentacji ESLint). !UWAGA! Bardzo ważne jest to, żeby „react-app”„react-app/jest” pozostały w „extends” naszego projektu (ponieważ “sprawdzają” mechanizmy Reacta)! 

Kiedy dodać swoje reguły do ESLint? 

Na pewno nie od razu. Sugerowałbym zacząć z rekomendowanym zestawem reguł, a ewentualne zmiany wprowadzać dopiero, gdy jakiejś będzie brakować lub któraś z nich będzie sprzeczna z wymaganiami waszego projektu. Oczywiście, nie zapomnijcie o tym, żeby dobrze przedyskutować to w zespole, aby cały zespół był zgodny i rozumiał, dlaczego taka zasada została zmieniona. 

Żeby dodać swoją zasadę lub zmienić działanie już istniejącej, musimy najpierw znaleźć ją w zbiorze reguł.

Następnie możemy dodać ją do sekcji rules configu (gdy chcemy, żeby odnosiła się do całego projektu) lub do sekcji overrides (jeśli ma działać tylko z pewną grupą plików) z jedną z trzech oczekiwanych wartości podanych niżej, która określać będzie to, jak linter będzie reagował na fragmenty kodu podpadające pod nią:

  • lub “off” – wyłączy zasadę 
  • 1 lub “warn” – linter będzie reagował warningiem 
  • 2 lub “error” – linter będzie reagował wyrzuceniem błędu i przerwaniem kompilacji  

Dla przykładu: „no-console”: „error” będzie blokował kompilacje aplikacji (wyrzucał error), gdy tylko linter wykryje console.log.

Zapraszamy do dyskusji

Patronujemy

 
 
More Stories
Huawei otwiera centrum innowacji w Londynie