Tasks in Visual Studio Code, czyli automatyzacja w formie konfigurowalnych zadań.

Visual Studio Code jest bardzo prostym edytorem z niskim progiem wejścia — instalujemy i możemy kodować bez większej konfiguracji. No może z zainstalowanymi kilkoma wtyczkami dedykowanej dla technologii. Jest również obok IDE spod szyldu JetBrains jednym z najpopularniejszych narzędzi dla web developera. Mam jednak wrażenie — co nieco patrząc na siebie — wiele przydatnych funkcjonalności nie jest szeroko znanych dla programistów. Tasks jest jedną z tych funkcjonalności, a pozwala zautomatyzować pracę poprzez wykonywanie zdefiniowanych przez ciebie skryptów.

Let’s task!

Visual Studio Code potrafi wykryć i uzupełnić automatycznie konfigurację z zadaniami o skrypty npm oczywiście ile w projekcie będzie skonfigurowany poprawny package.json. Oprócz tego wspiera również inne języki i narzędzia im dedykowane, lecz z oczywistych względów skupię się wyłącznie na front-endzie.

Wróćmy do definicji naszego pierwszego zadania. Niech będzie odpowiedzialne za uruchomienie skryptu npm z testami jednostkowymi napisanymi w jest. Jako że mamy możliwość wygenerowania go automatycznie to uruchamiamy Command Palette (CMD+Shift+P/CTRL+Shift+P) i wpisujemy Tasks: Configure Task.

Naszym oczom ujawniła się lista wszystkich wykrytych skryptów npm w projekcie. Jako że chce skonfigurować zadanie pod uruchomienie testów jednostkowych, to szukam odpowiadającą mi opcję.

Po wybraniu utworzony zostanie w naszym projekcie plik tasks.json w katalogu .vscode o następującej strukturze:

{
  "version": "2.0.0",
  "tasks": [
    {
      "type": "npm",
      "script": "test:unit",
      "problemMatcher": [],
      "label": "npm: test:unit",
      "detail": "jest"
    }
  ]
}

• type → Typ zadania. Może to być jeden ze wspieranych out of the box przez Visual Studio Code jak widoczny npm jak i podstawowe shell czy process.
• script → jest to pole dedykowane pod typ npm. Wskazujemy jaki skrypt chcemy uruchomić.
• problemMatcher → przyjmuje informacje, w jaki sposób ma przetwarzać output skryptu w celu prawidłowego wyświetlenia błędów czy ostrzeżeń w zakładce Problems. Więcej możecie przeczytać tutaj.
• label → nazwa zadania, która będzie wyświetlana m.in. w panelu dostępnych zadań w projekcie (do którego przejdziemy za chwilę).
• detail → jest to dodatkowy opis zadania, który wyświetla się pod nazwą zadania.

Dobrze, mamy zdefiniowane zadanie. To, w jaki sposób można je uruchomić? Pierwszym sposobem jest otworzenie panelu Go to file (CMD+P/CTRL+P) i wpisanie “task ” (na końcu jest spacja).

Jak widać mamy nasze zadanie. Wyświetla się przed chwilą wspomniany label (npm: test:unit) jak i detail (jest). Uruchommy go.

Działa, świetnie! Teraz dosłownie nie odrywając rąk od klawiatury, jesteśmy w stanie uruchomić w ekspresowym tempie testy jednostkowe. Jednak nie jestem tym do końca usatysfakcjonowany. Potrzebowałbym dodatkowe zadanie, które uruchomi mi wyłącznie testy dla pliku, w którym obecnie się znajduję. W tym celu skopiuje istniejące zadanie i trochę je zmodyfikuję.

{
  "type": "shell",
  "command": "npm run test:unit -- --runTestsByPath ${fileDirname}/${fileBasenameNoExtension}.*${fileExtname}",
  "group": "test",
  "label": "Run unit tests for current file",
  "detail": "npm run test:unit -- --runTestsByPath"
}

Zmieniłem typ na shell, mówiąc, że zadanie ma wykonać polecenie w bashu (lub innej powłoce, jaką masz skonfigurowaną w systemie). Pod command kryje się to polecenie, jakie zdefiniujemy. Dodatkowo skorzystałem z pomocy wbudowanych zmiennych, które pozwolą skonstruować dynamicznie ścieżkę, która będzie wskazywać na aktywny plik testowy czy plik z logiką biznesową. Dzięki temu zadanie będzie elastyczne, ponieważ zadanie poprawnie będzie działać gdy będziemy znajdować się w pliku z kodem (foo.js) jak i w samych plikach testowych (foo.spec.js czy foo.test.js). Oczywiście przyjmując konwencję, że testy są na tym samym poziomie co kod, ponieważ w taki sposób skonfigurowałem komendę. Krótkie wyjaśnienie co kryje się pod tymi zmiennymi:

• fileDirname — absolutna ścieżka do pliku
• fileBasenameNoExtension — nazwa pliku bez rozszerzenia
• fileExtname — rozszerzenie pliku

Po listę wszystkich zmiennych odsyłam do dokumentacji. Zobaczmy zadanie w akcji:

Działa wyśmienicie więc praca z testami będzie zdecydowanie wydajniejsza. Chociaż wydaje mi się, że możemy zrobić jeszcze jedną rzecz. Wszyscy kochamy skróty klawiaturowe, więc przypiszmy jeden do tego zadania. W tym celu należy zaktualizować keybindings.json o następującą formułkę:

{
  "key": "ctrl+shift+t",
  "command": "workbench.action.tasks.runTask",
  "args": "Run unit tests for current file"
}

• key — skrót klawiaturowy
• command — wskazujemy, że skrót ma odpalić zadanie…
• args — …o danej nazwie, czyli zgodnie ze zdefiniowanym polem label

Voilà! Mamy wszystko, co chcieliśmy osiągnąć. Stworzyliśmy zadanie, które uruchomi test jednostkowy dla pliku, w którym obecnie się znajdujemy i do tego przypisaliśmy do niego skrót klawiaturowy. Lepiej być nie mogło. Produktywność wskoczyła o kilka poziomów w górę!