Możesz prawie zawsze założyć się, że dobry kawałek pisma był dobroczyńcą dobrej edycji. Pod tym względem, kod nie różni się od prozy. Jedną z korzyści, którymi cieszymy się jako programiści, są edytory lub lintery kodu, które mogą być wbudowane w nasze procesy robocze.

Linting jest aktem lub procesem sprawdzania kodu pod kątem błędów dowolnego rodzaju. Istnieje wiele pomysłów na to, jak zoptymalizować efektywność danego fragmentu kodu. Ale sprawdzenie, czy jest on wolny od błędów i zgodny z określonym przewodnikiem stylu jest podstawą. Czasami jest to kwestia spójności i czytelności, czasami jest to kwestia tego, aby kod był w stanie działać w pierwszej kolejności.

Jeśli chodzi o JavaScript linting, istnieje garść narzędzi, które się wyróżniają. Przyjrzyjmy się czterem linterom, które mogą pomóc w rozpoczęciu lub udoskonaleniu procesu lintingu: JSLint, standardJS, JSHint i ESLint.

JSLint

JSLint został stworzony w 2002 roku przez Douglasa Crockforda, który również napisał to, co jest prawdopodobnie jedną z najlepszych książek o JavaScript. JSLint wnosi prostotę i szybkość do stołu. Ale jest również bardzo opiniotwórczy, co może być błogosławieństwem lub przekleństwem.

JSLint składa się z pojedynczej strony, która jest zdominowana przez pole tekstowe, gdzie możesz wkleić swój kod. Kliknij przycisk „JSLint” i wszelkie błędy, stylistyczne, składniowe lub inne będą wyświetlane pod polem tekstowym. Pod polem tekstowym znajduje się mała lista opcji, konfigurowalnych za pomocą pól wyboru. Opcje obejmują tolerowanie dodatkowych białych spacji, użycie słowa kluczowego 'this’ (które jest odradzane przez Crockforda w jego wykładach), oraz włączenie Node.js.

Jeśli nie jesteś zobowiązany do żadnego konkretnego przewodnika stylu i chcesz mieć wiarygodne źródło do sprawdzenia kodu dla Ciebie, JSLint jest świetną opcją. Jest szczególnie skuteczny do testowania fragmentów kodu lub jeśli szukasz sposobu na szybkie sprawdzenie małych projektów – może to być statyczna witryna z jedną stroną, która zawiera tylko jeden plik JavaScript.

standardJS

Bazując wyłącznie na gwiazdkach GitHuba, standardJS jest najpopularniejszą opcją, z prawie 19 000 gwiazdek. Jest on całkowicie opiniotwórczy, co oznacza, że nie jest w ogóle konfigurowalny. Ale, jeśli nie jesteś zobowiązany do żadnego konkretnego przewodnika stylu, może to być błogosławieństwem. Pochodzi w formie Node CLI, i może być zainstalowany globalnie lub jako zależność rozwojowa przy użyciu terminala lub wiersza poleceń do wyboru:

$ npm install standard --global// or$ npm install standard --save-dev

Ponieważ standardJS ma Node i npm jako warunki wstępne, i ponieważ jest uruchamiany z wiersza poleceń lub przez skrypt npm, poprzeczka jest podniesiona nieco z poziomu JSLint. Ale ponieważ nie jest konfigurowalny, nie masz zbyt wiele innych powodów do zmartwień. Możesz uruchomić go z linii poleceń jako polecenie jednowyrazowe i sprawdzi każdy plik z rozszerzeniem .js w twoim bieżącym katalogu roboczym.

Wszystkie błędy, które znajdzie, zostaną wypisane do twojego terminala lub wiersza poleceń. Możesz oczekiwać, że zobaczysz wyjście podobne do tego przykładu ze standardowej dokumentacji JS:

$ standardError: Use JavaScript Standard Stylelib/torrent.js:950:11: Expected '===' and instead saw '=='.

Jeśli musisz określić plik lub katalog, możesz dołączyć ścieżkę jako argument i użyć dzikich kart. StandardJS akceptuje również symbole wieloznaczne. W tym przykładzie, standardJS będzie szukał i sprawdzał wszystkie pliki JavaScript w katalogu src i jego podkatalogach:

$ standard "src/**/*.js" --fix

Flaga --fix po ścieżce do pliku jest opcją automatycznego usuwania błędów w miarę ich znajdowania. Może to być świetna oszczędność czasu, ale może to być również świetne ćwiczenie do nauki samodzielnego naprawiania błędów.

Jeśli chcesz poznać konwencje i zasady, których używa StandardJS przed podjęciem decyzji czy go używać, pełną listę można znaleźć tutaj. StandardJS jest świetną opcją dla tych z was, którzy szukają szybkiego i niezawodnego sposobu na rozpoczęcie pracy z linterem JavaScript.

JSHint

JSHint rozpoczął się jako fork JSLint. Celem było stworzenie bardziej konfigurowalnego lintera. Jeśli używałeś standardJS, lub innego opiniotwórczego lintera, i szukasz sposobu na rozpoczęcie dostosowywania własnych reguł lintowania, JSHint może być dla Ciebie. Posiada większość zalet wyżej wymienionych linterów i jeszcze kilka.

Jak JSLint, strona główna JSHint posiada pole tekstowe, gdzie możesz wkleić kod. Pole Metrics na prawo od pola tekstowego będzie się aktualizować w czasie rzeczywistym, jak piszesz, tallying bieżącą listę statystyk o swoim kodzie, takich jak liczenie, ile funkcji zawiera. Oczywiście, wyświetla również wszystkie znalezione błędy.

Jeśli nie podoba Ci się metodologia kopiuj/wklej i chcesz ją zastosować w swoim projekcie, JSHint może być zainstalowany globalnie lub jako zależność od projektu za pomocą npm:

$ npm install jshint --global// or$ npm install jshint --save-dev

Po zainstalowaniu użyjesz CLI do sprawdzenia poprawności swojego kodu. Oto dwie przykładowe komendy, które sprawdzają pojedynczy plik i katalog, odpowiednio:

$ jshint index.js// or$ jshint src/

W pierwszym przykładzie, JSHint podlinkuje plik index.js, a w drugim przeszuka rekursywnie katalog 'src/’ i podlinkuje wszystkie pliki JavaScript, które znajdzie. JSHint wypisze wszystkie błędy, które znajdzie w twoim terminalu.

Jeśli nie zależy ci na dostosowaniu, JSHint może być użyty tak, jak opisano w powyższych przykładach i będzie działał dobrze. Ale od tego miejsca złożoność może znacznie wzrosnąć, ponieważ JSHint jest całkowicie konfigurowalny, a także eksponuje API, co oznacza, że może być używany jako moduł JavaScript w twoich własnych plikach JavaScript.

Niestandardowa konfiguracja, która powinna być przechowywana w pliku o nazwie .jshintrc, plik może wyglądać tak:

{"esversion": 5,"eqeqeq": true,"strict": true}

Ten przykład, od góry do dołu, ustawia wersję ECMAScript na 5, wymaga użycia trzech znaków równości ( === lub !==) w przeciwieństwie do dwóch (== lub !=) przy porównywaniu wartości, i wymusza tryb ścisły. Możesz dołączyć swoje własne konfiguracje, podając ścieżkę do pliku .jshintrc za flagą -- config w wierszu poleceń lub deklarując je jako atrybut 'jshintConfig’ w pliku package.json projektu. JSHint użyje swoich domyślnych opcji dla wszystkich reguł, których nie dostosujesz.

Opcja wiersza poleceń może wyglądać tak:

// looks for '.jshintrc' in the current directory$ jshint --config './.jshintrc'

Ale opcja package.json może wyglądać tak:

{ "jshintConfig": { "esversion": 5, "eqeqeq": true, "strict": true }}

Możesz użyć tych podstaw, aby rozpocząć drogę dostosowywania własnych reguł lintingu za pomocą JSHint. Jeśli szukasz więcej, oficjalne dokumenty zawierają wyczerpujący opis tego, jak używać API JSHint i wszystkich sposobów, w jakie można je dostosować do swoich potrzeb.

ESLint

Gwiazdy GitHuba na bok, jeśli chodzi o lintowanie JavaScript, ESLint jest prawdopodobnie linterem widzianym najczęściej na wolności i będzie go-to dla wielu ludzi. W swojej własnej dokumentacji porównuje się do JSLint i JSHint w odniesieniu do metod, których używa do parsowania JavaScript. I, podobnie jak w przypadku JSHint, możesz ułatwić sobie pracę używając domyślnych ustawień i dodawać modyfikacje, gdy zmieniają się twoje preferencje lub potrzeby.

Aby rozpocząć pracę z ESLint, zainstaluj go globalnie lub jako zależność rozwojową:

$ npm install eslint --save-dev// or$ npm install eslint --global

Jeśli zainstalujesz ESLint globalnie, jego konfiguracje będą miały zastosowanie do każdego i wszystkich plików projektów, przeciwko którym go uruchomisz. Ale jeśli chcesz mieć różne konfiguracje dla różnych projektów, możesz zainstalować go jako zależność rozwojową i utworzyć inny plik konfiguracyjny dla każdego projektu. Pamiętaj, że jeśli ESLint jest zainstalowany jako zależność od projektu, a nie globalnie, musisz uruchomić plik wykonywalny z folderu node_modules w następujący sposób:

$ ./node_modules/.bin/eslint --init

Po uruchomieniu powyższego polecenia, zostaniesz przeprowadzony przez konfigurację ESLinta za pomocą serii pytań. (Uwaga: Niezależnie od tego, jak bardzo planujesz dostosować swoje reguły lintingu, musisz zacząć od tego kroku, ponieważ ESLint potrzebuje pliku .eslintrc, który zostanie wygenerowany przez ten proces, zanim będzie mógł lintować twój kod.)

Pierwszym pytaniem, jakie zostanie ci zadane, jest to, jak skonfigurować ESLint. Masz trzy opcje: użyć popularnego przewodnika po stylach, odpowiedzieć na pytania dotyczące twojego stylu, lub pozwolić ESLintowi skonfigurować się za ciebie poprzez sprawdzenie twoich plików, aby zdecydować jak ustawić reguły. Jeśli perspektywa samodzielnego konfigurowania go od razu wydaje się zastraszająca, możesz skorzystać z popularnego przewodnika po stylach opracowanego przez jedną z kilku znanych organizacji.

Niezależnie od tego, którą ścieżką pójdziesz, ESLint użyje twoich odpowiedzi do wygenerowania pliku o nazwie .eslintrc w bieżącym katalogu roboczym. Jest to plik, który zmodyfikujesz, jeśli będziesz chciał wprowadzić zmiany w regułach lintingu w późniejszym czasie.

Oto przykładowy plik .eslintrc w formacie JSON, który używa domyślnych reguł przewodnika po stylu Airbnb JavaScript i zawiera dwie niestandardowe reguły wyłączające tryb ścisły i zezwalające na console.log() deklaracje:

{ "extends": "airbnb-base", "rules": { "strict": "off", "no-console": "off" }}

Jeśli zdecydujesz się odpowiedzieć na pytania dotyczące Twojego stylu, zapyta Cię o takie rzeczy, jak wersja ECMAScript, której używasz, czy wolisz tabulatory czy spacje, średniki czy nie, oraz czy używasz JSX i/lub React. Wsparcie dla Reacta i dodatkowe wtyczki sprawiają, że ESLint jest najlepszym wyborem dla programistów Reacta. Przynajmniej dla tych, którzy dopiero zaczynają swoją przygodę z lintingiem.

Po zainstalowaniu ESLinta i wygenerowaniu pliku .eslintrc, możesz użyć CLI, aby rozpocząć linting swojego kodu. ESLint domyślnie szuka pliku .eslintrc, więc nie trzeba podawać żadnych konfiguracji w wierszu poleceń. Możesz jednak użyć różnych flag, aby zmienić zachowanie ESLinta. W poniższym przykładzie, flaga -- quiet mówi ESLintowi, aby wyświetlał tylko błędy, w przeciwieństwie do ostrzeżeń i błędów. Flaga --fix mówi mu, aby próbował automatycznie naprawić wszystkie błędy, które znajdzie.

// run eslint against file1.js$ ./node_modules/.bin/eslint file1.js// run eslint against file1.js and file2.js with flags to modify behavior$ ./node_modules/.bin/eslint file1.js file2.js --quiet --fix

Podobnie jak w przypadku innych CLI, które omówiliśmy, możesz użyć dzikich kart i ścieżek plików zamiast konkretnych nazw plików, jeśli zajdzie taka potrzeba. Chociaż ESLint jest wysoce konfigurowalny, ułatwia naukę dzięki przystępnemu przewodnikowi po domyślnej metodzie konfiguracji. Jeśli chcesz się naprawdę zagłębić w konfiguracje, oficjalna dokumentacja zawiera świetne wyjaśnienia wszystkiego, co możesz zrobić z ESLint.

Następne kroki i wnioski

Podsumowanie:

  • JSLint jest świetny do sprawdzania fragmentów lub pojedynczych plików. Jednym z jego potencjalnych minusów jest to, że nie nadaje się do dużych projektów.
  • StandardJS jest idealny dla tych, którzy chcą zacząć z niewielkim lub żadnym zamieszaniem i/lub wbudować linter do swoich przepływów pracy i skryptów budowania. Ale, nie jest konfigurowalny. Więc jeśli potrzebujesz stworzyć niestandardowe reguły, prawdopodobnie będziesz chciał spojrzeć na JSHint lub ESLint.
  • JSHint może być również zainstalowany przez npm i jego reguły lintowania są całkowicie konfigurowalne. To może być dobre lub złe, w zależności od twoich potrzeb i poziomu umiejętności. Możesz zacząć od domyślnych reguł i dostosować je w razie potrzeby. Posiada również pojedynczą stronę, którą można wykorzystać do lintowania fragmentów lub pojedynczych plików.
  • ESLint może być zainstalowany przez npm i wbudowany w przepływy pracy tak jak JSHint. A format pytań i odpowiedzi w CLI może pomóc Ci w nauce, gdy zaczynasz. W formie out-of-the-box zawiera standardy branżowe, przewodniki stylu open source i zasady lintingu, które można zastosować do każdego projektu.

Wszystkie cztery lintery, którym się przyjrzeliśmy, są niezawodne i renomowane dzięki temu, że są używane i rozwijane przez znanych ludzi i organizacje w społeczności programistów internetowych. Każdy mógłby być dobrze obsłużony przez którykolwiek z nich. Jeśli opanowałeś podstawy omówione w tym artykule, świetnym następnym krokiem będzie nauczenie się, jak zintegrować je dalej z twoim tokiem pracy za pomocą skryptów npm lub bundlera takiego jak Webpack.

Każde narzędzie jest tylko tak dobre, jak sposób, w jaki je wykorzystujesz. Dotyczy to zarówno linterów, jak i kodu, który pomagają udoskonalić. Nawet jeśli tworzysz sam i nie musisz się martwić o spójność kodu w zespole programistów, nadal możesz skorzystać z wbudowanego edytora. Jest to niezwykle skuteczny sposób na nauczenie się poprawnego pisania JavaScriptu. Niezależnie od tego, którego lintera używasz, używanie lintera może Ci tylko pomóc. Możesz założyć się, że jakość Twojego kodu poprawi się, podobnie jak Twoje umiejętności jako dewelopera.

LogRocket: Debugowanie błędów JavaScript łatwiejsze dzięki zrozumieniu kontekstu

Debugowanie kodu jest zawsze żmudnym zadaniem. Ale im lepiej rozumiesz swoje błędy, tym łatwiej jest je naprawić.

LogRocket pozwala Ci zrozumieć te błędy w nowy i unikalny sposób. Nasze rozwiązanie monitorujące frontend śledzi zaangażowanie użytkownika w Twój JavaScript frontend, aby dać Ci możliwość dowiedzenia się, co dokładnie zrobił użytkownik, co doprowadziło do błędu.

LogRocket Dashboard Free Trial Banner

LogRocket rejestruje logi konsoli, czasy ładowania strony, stacktraces, powolne żądania/odpowiedzi sieciowe z nagłówkami + ciałami, metadane przeglądarki oraz logi niestandardowe. Zrozumienie wpływu Twojego kodu JavaScript nigdy nie będzie łatwiejsze!

Wypróbuj go za darmo.

.

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany.