Własna konfiguracja do TSLint | Piotr Kowalski — JavaScript, Front-end oraz Node.js

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:

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).
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 nadpisuje tslint: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 plikiem tslint.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.