ESLint oraz Prettier są dwoma narzędziami, które pozwalają nam na ujednolicenie składni kodu wytwarzanego przez nasz zespół developerski. Lintowanie oraz auto-formatowanie kodu jest również niezwykle przydatne podczas samodzielnego programowania. Ciągle pojawiające się czerwone podkreślenia w naszym edytorze wymuszają na nas stosowanie dobrych praktyk programistycznych oraz wyłapują wiele podstawowych błędów (takich jak „literówki”) już podczas pisania naszego programu. Wszystko to prowadzi do tego, iż posiadamy finalnie czysty kod w repozytorium.
Czysty kod w repozytorium
W dzisiejszym wpisie dowiemy się w jaki sposób zintegrować ESLint oraz Prettier z edytorem Visual Studio Code oraz odpowiednio skonfigurować wszystkie najważniejsze funkcjonalności. Dzięki temu jakoś kodu w naszym zespole będzie mogła być utrzymana na odpowiednim poziomie.
ESLint
Zaczniemy od ESLint. W pierwszej kolejności instalujemy z npm jako dev dependency paczkę eslint yarn add -D eslint.
W celu konfiguracji ESLint tworzymy w nadrzędnym katalogu naszego projektu plik .eslintrc. Plik ten zawiera konfigurację w formacie pliku JSON. Plik ten może, ale nie musi posiadać rozszerzenie. Nieco więcej na temat nazewnictwa oraz lokalizacji tego pliku można znaleźć tutaj.
Poniżej znajduje się najbardziej podstawowa konfiguracja, która pozwoli nam na pisanie kodu z wykorzystaniem najnowszej składni JavaScript i rekomendowanego stylu pisania kodu:
{
"parserOptions": {
"ecmaVersion": "2018" // korzystamy z najnowszej składni JS
},
"extends": [ // możemy korzystać z gotowych reguł ESLint
"eslint:recommended" // więc korzystamy z tych rekomendowanych przez twórców ESLinta
],
"rules": {
"no-console": "off" // możemy nadpisać każdą z rekomendowanych reguł
},
"env": {
"browser": true // określając środowisko, globalne wartości takie jak 'window' lub 'console' nie będą raportowane jako błąd
}
}Jak widać, wszystkie gotowe już reguły możemy nadpisać swoimi własnymi. W powyższym przypadku, rekomendowane reguły ESLint nie pozwalają umieszczać console.log w naszym kodzie. Listę wszystkich reguł zaimplementowanych jako eslint:recommended znajdziemy pod tym linkiem.
My jednak chcemy mieć możliwość umieszczania console.log w naszym kodzie bez wyrzucania błędu przez ESLint. Możemy to osiągnąć nadpisując jedną z rekomendowanych reguł – tutaj: no-console. Reguły nadpisujące umieszczamy pod property rules (linia nr 8 w powyższym kodzie).
Istnieje jeszcze pośrednia metoda wyłapywania błędów przez ESLint, czyli wyświetlanie w konsoli warningów, które nie przerwą działania (bądź budowania) aplikacji a mimo wszystko zasygnalizują nam, że coś w kodzie wymaga naszej uwagi. Zamienienie błędów na ostrzeżenia jest bardzo proste – nadpisując reguły, ich wartość ustawiamy na warn, czyli u nas: "no-console": "warn". Możliwe wartości jakich możemy tutaj użyć to off, warn, error" Możemy również posługiwać się cyframi: 0 = off, 1 = warn, 2 = error.
ESLint możemy uruchomić poprzez linię komend npx eslint src (zakładając, że kod naszej aplikacji znajduj się w folderze src). Wszystkie błędy składniowe łamiące zasady ustawione przez nas w pliku konfiguracyjnym zostaną wyświetlone w terminalu. Nie jest to jednak zbyt wygodna metoda, dlatego też dużo lepszą opcją jest integracja ESLint bezpośrednio z VS Code – wtedy wszystkie występujące problemy zobaczymy w edytorze podkreślone na czerwono, jeżeli reguła będzie ustawiona na error bądź zielono, gdy jest zdefiniowana jako warn.
W tym celu musimy w VS Code zainstalować rozszerzenie ESLint. Po przeładowaniu edytora i otworzeniu pliku .js zawierającego błędy składniowe, zobaczymy czerwone bądź zielone podkreślenia. Jeżeli chcemy się dowiedzieć dlaczego dana linia kodu jest podkreślona, najeżdżamy na nią kursorem i odczytujemy krótki opis błędu.
Zazwyczaj opis błędu jest wystarczający aby go zrozumieć, gdybyśmy jednak chcieli zgłębić bardziej co jest nie tak z naszym kodem, możemy odczytać nazwę reguły (podkreślona przeze mnie na pomarańczowo), udać się na znaną już nam stronę z opisami reguł i doczytać tam nieco więcej.
Drugim miejscem w którym wyświetlają się błędy zgłaszane przez ESLint jest dolny panel VS Code:
Prettier
Prettier jest narzędziem, które dba o poprawne formatowanie naszego kodu. Podobnie jak w przypadku ESLint, instalujemy go jako dev-dependency: yarn add -D prettier. Instalujemy również dodatek do VS Code o nazwie Prettier – Code formatter. Poprawne formatowanie również pozwoli nam zachować oczekiwany przez nas czysty kod w repozytorium.
Podstawową konfigurację Prettiera jesteśmy w stanie „wyklikać” na tej stronie. Klikamy w lewym dolnym rogu na przycisk Show options i ustawiamy wedle naszych preferencji. Następnie piszemy kod w środkowym oknie i w oknie po prawej stronie widzimy ten sam kod sformatowany przez Prettier. Gdy jesteśmy już zadowoleni z naszej pracy, klikamy w przycisk Copy config JSON.
Teraz wystaczy w głównym katalogu naszego projektu stworzyć plik konfiguracyjny o nazwie .prettierrc i wkleić tam nasze ustawienia.
W celu sformatowania wszystkich plików .js i .jsx w naszym kodzie uruchamiamy w terminalu komendę npx prettier --write \"**/*.+(js|jsx)\"". Jeżeli w naszym projekcie znajdują się foldery w których nie chcemy formatować z jakiegoś powodu znajdujących się tam plików, umieszczamy je w pliku .prettierignore w katalogu głównym.
Ponownie, uruchamianie tej samej komendy w terminalu jest niezbyt wygodne. Możemy za to formatować nasz dokument za każdym razem gdy go zapisujemy – musimy tylko upewnić się, że w ustawieniach VS Code flaga editor.formatOnSave jest ustawiona na true.
Walidacja kodu podczas commitu
Integracja ESLint oraz Prettier z VS Code pozwala nam od razu w czasie pisania kodu wyłapywać niemal wszystkie problemy zgłaszane przez ESLint oraz odpowiednio formatować pliki przy zapisie. Najważniejszym jednak momentem w którym powinniśmy upewnić się, czy nasz kod jest poprawnie sformatowany jest faza commitowania. To wtedy powinniśmy uruchomić obydwa narzędzia w wierszu poleceń i w przypadku braku błędów – pozwolić na commit. Do tego załóżmy, iż nasza aplikacja jest bardzo rozbudowana. Nie chcemy więc lintować wszystkich plików, tylko te które zostały przez nas zmienione i są przygotowane do commitu.
W celu osiągnięcia obydwu tych funkcjonalności, posłużymy się dwoma narzędziami: husky oraz lint-staged
yarn add -D lint-staged husky
husky pozwoli nam na uruchomienie tzw. pre-commit git hooks, czyli zdefiniowanych przez nas skryptów, które zdecydują o tym, czy nasz commit zostanie wykonany czy odrzucony.
lint-staged uruchomi ESLint tylko na plikach, które są dodane (staged) do commitu.
Bardzo dobrym połączeniem będzie więc uruchomienie lint-staged jako skrypt przed commitem. Jeżeli ESLint znajdzie błędy składniowe w edytowanych przez nas plikach, zwróci błąd przez co zablokuje możliwość wykonania commitu.
lint-staged wymaga niewielkiego pliku konfiguracyjnego o nazwie .lintstagedrc umieszczonego w głównym katalogu:
{
"linters": {
"*.js": [ // wszystkie pliki JS
"eslint" // przeskanuj za pomocą ESLint
],
"*.+(js|jsx|json|css|scss|ts|tsx)": [ // wszystkie pliki z tym rozszerzeniem
"prettier --write", // sformatuj za pomocą Prettier
"git add" // i dodaj do plików gotowych do commitu
]
}
}Skrypty pre-commit możemy zdefiniować w pliku package.json:
{
"main": "index.js",
"scripts": {
"lint": "eslint src",
"format": "npm run prettier -- --write",
"prettier": "prettier \"**/*.+(js|jsx|json|css|scss|ts|tsx)\"",
"precommit": "lint-staged"
},
"devDependencies": {
"eslint": "^5.5.0",
"husky": "^0.14.3",
"lint-staged": "^7.2.2",
"prettier": "^1.14.2"
}
}Stosując wszystkie wymienione tutaj zasady możemy być pewni, iż będziemy posiadać całkiem czysty kod w repozytorium.
