Tak, wiem. TSLint is deprecated. Aczkolwiek JESZCZE nie jest. JESZCZE istnieją projekty, gdzie głównym narzędziem do lintowania jest TSLint. I dobrze.
Dziś przedstawiam Wam jak zrobić własną konfigurację do TSLinta. W sumie bardzo podobnie (jak nie identycznie) tworzy się konfigurację do ESLinta. Oczywiście to inny projekt (następca TSLinta) więc i nazwy kluczy do reguł mogą się zmienić, ale schemat jest MEGA podobny.
1. Stwórz repozytorium na GitHub
W nazwie projektu ważne, jest zawarcie dwóch rzeczy:
- prefiksu
tslint-config-
— który informuje, jakiego typu jest to projekt - postfiksu np.
piecioshka
— który informuje, kto używa tej paczki (np. organizacja) albo kto jest autorem (np. my sami)
Bardzo dobrą praktyką jest tworzenie takich konfiguracji w zespołach projektowych.
Wtedy projekt z konfiguracją może się nazywać tslint-config-NAZWA_FIRMY
.
Przykłady:
- https://www.npmjs.com/package/tslint-config-airbnb
- https://www.npmjs.com/package/tslint-config-silind
- https://www.npmjs.com/package/tslint-config-scc
W moim przypadku jest to repozytorium:
https://github.com/piecioshka/tslint-config-piecioshka
2. Stwórz katalog na dysku, a w nim trzy pliki
-
README.md
- Informacja jak użyć Twojego projektu
- Jeśli paczka została opublikowana na #npm to warto dodać badge (odznaki), które mogą np. prezentować ilość pobrań, oraz informację, jaka jest najnowsza opublikowana wersja.
-
package.json
- Oczywiście, warto zdefiniować takie pola jak:
name, version, license, description, author
. - Jeśli chcesz opublikować paczkę po to, aby mogli z niej korzystać też
inny deweloperzy, to zadbaj o słowa kluczowe, tj. klucz
keywords
. - Warto zdefiniować również klucz
files
, aby opublikować tylko wybrane pliki i katalogi — w tym przypadku będzie to tablica trzyelementowa. - Ostatnim dobrym pomysł jest dodanie informacji o repozytorium, z którego pochodzi dana paczka, dzięki temu ktoś, kto znajdzie projekt na #npm będzie mógł zobaczyć źródła projektu przed jego pobraniem (no, chyba że użyje #npmview).
- Oczywiście, warto zdefiniować takie pola jak:
-
index.js
-
W tym pliku zdefiniuj swoje reguły dla #TSLinta. Pamiętaj, że i tak każdy ma możliwość nadpisania Twoich wartości. Przykład:
module.exports = { "extends": [ "tslint:recommended" ], rules: { "variable-name": { "options": [ "allow-leading-underscore" ] } } };
- Ze względu, że paczka, którą definiujesz, będzie w #npm, który jest rejestrem paczek dla Node.js, zaimplementuj moduł w stylu CommonJS.
- Warto, aby Twoja konfiguracja rozszerzała już istniejącą, która to ma zdefiniowane wartości dla pozostałych pól, tak aby nie korzystać (albo aby właśnie korzystać) z domyślnych. W swojej konfiguracji postaraj się nadpisać tylko te, które faktycznie zależą od Twojego stylu pisania.
-
3. Publikacja
Nadszedł czas na publikację. Stwórz commit
, a potem:
npm publish
tym samym, Twoja paczka będzie już dostępna w rejestrze npm.
Na koniec warto zmiany wysłać na serwer za pomocą git push
.
4. Użycie
-
tslint.json
Dodać do tablicy
extends
np.tslint-config-piecioshka
.
Uwaga: Kolejność ma znaczenie. Przykład:"extends": [ "tslint:recommended", "tslint-config-piecioshka" ],
W tym przypadku konfiguracja
tslint-config-piecioshka
nadpisujetslint:recommended
.
5. Zainstalować
W dowolnym projekcie można już zainstalować naszą paczkę.
-
tslint-config-piecioshka
npm i -D tslint-config-piecioshka
W przeciwnym przypadku będzie error:
Failed to load /Users/piecioshka/projects/example/tslint.json: Invalid "extends" configuration value - could not require "piecioshka". Review the Node lookup algorithm (https://nodejs.org/api/modules.html#modules_all_together) for the approximate method TSLint uses to find the referenced configuration file.
Dlaczego używam
-D
? Konfiguracja do lintera nie dodaje żadnego nowego zachowania do aplikacji, więc jest czysto deweloperska.
6. Uruchomić proces lintowania
-
package.json
Dodać zadanie do run-scripts:
"scripts": { "lint": "tslint -p ." }
Gdzie
-p
oznacza katalog z plikiemtslint.json
. Na zakończenie uruchomić:npm run lint
… i zacząć poprawiać “bugi”!
•
FAQ
- Co to jest proces "lintowania" kodu?
-
Proces polegający na weryfikacji kodu pod kątem reguł sprawdzające
sposób jego zapisu. Dla przykładu, czy po wyrażeniu if
należy napisać spację, czy też nie. Dla interpretera to bez znaczenia,
ale aby uzyskać spójność kodu między deweloperami, warto zdefiniować
taki proces, który POKAŻE niedoskonałości.
Inny rozwiązaniem jest używanie Prettiera, który to na podstawie konfiguracji automatycznie poprawi kod.