Można kodować w Notatniku? Można! Tylko po co? Można kodować w najdroższym IDE na rynku? Można! Tylko po co, skoro w 95% nie wykorzystujesz jego możliwości? Można zbudować sobie IDE pod siebie? Można! I dziś opowiem Wam jak to zrobić przy pomocy VSCode.


Przemek Suchodolski. Frontend developer z pasją i zamiłowaniem do JS’a. Fan „czystego kodu” i Test Driven Development’u. Z komercyjnym programowaniem związany od 2012 roku. W swojej karierze miał okazję pracować dla koreańskiej korporacji, amerykańskiego startup’u czy polskiego software-house’u. Nieśmiało stawia swoje pierwsze kroki jako prelegent oraz bloger (przemuh.pl).


Jesteś tak dobry jak…

Kilka miesięcy temu skończył się mundial w Rosji. Polacy niestety odpadli po trzech meczach fazy grupowej. Słyszałem wtedy wiele komentarzy w stylu:

Jesteś tak dobry jak twój ostatni mecz

Postanowiłem sparafrazować to powiedzenie w kontekście programisty i wyszło mi, że:

Jesteś tak dobry jak narzędzia, z których korzystasz…

Coś mi tu nie pasowało, bo w sumie możesz korzystać z topowych, najdroższych narzędzi na rynku, a nadal być kiepskim programistą… Dlatego koniec końców wyszło, że:

Jesteś tak dobry, jak Twój poziom ogarnięcia narzędzi, z jakich korzystasz.

Zgadzacie się z tym?

Jako programiści jesteśmy rzemieślnikami. Naszym dziełem jest kod. Wychodzi spod naszych palców niczym przepiękne dźwięki wydawane przez trącanie strun w gitarze. I tak jak gitarzysta nic nie zrobiłby bez gitary, tak my — programiści, nie moglibyśmy programować bez narzędzi takich jak np. IDE (Integrated Development Environment). Umówmy się — pisanie kodu w notatniku jest dla hardcorów. Im lepiej posługujemy się tymi narzędziami, tym lepszymi rzemieślnikami jesteśmy.

Mój pierwszy IDE

Kiedy w 2012 roku zaczynałem swoją komercyjną przygodę z programowaniem, moim pierwszym IDE był NetBeans. Używałem go na studiach przy pisaniu programów na zaliczenia w Javie. Dodatkowo kodowałem w nim moje pierwsze strony w PHP. JavaScript wtedy był dla mnie czarną magią. Po przyjściu na staż do Samsunga przerzuciłem się na Aptanę. Uznałem, że lepiej będzie używać tego, co wszyscy — jeśli będę miał z czymś problem, to na pewno ktoś mi pomoże. Mijały miesiące, a na rynek wkroczył nowy gracz — WebStorm od JetBrains. Jeden kumpel się na niego przerzucił, potem drugi, trzeci. Pomyślałem, że i ja spróbuję.

Tym bardziej, że pracodawca fundował licencję, która na tamte czasy do tanich nie należała. Dodatkowym impulsem do przesiadki na WebStorma był plugin, napisany przez mojego kolegę z zespołu — Artura Barcickiego. Plugin ten wyświetlał logi z aplikacji, którą wysyłaliśmy zdalnie na telewizor. Pisaliśmy wtedy aplikacje na platformę SmartTV i taki logger był niesamowicie przydatny. Żadne inne IDE (poza Samsungowym tworem, bazującym na Eclipse) nie miało takiego loggera. Dawało to mega boost do produktywności.

Co jeszcze urzekło mnie w Webstormie, czego nie miał NetBeans i Aptana? Może ten double-shift, który przeszukiwał cały projekt pod kątem wpisanej nazwy? Może to, że dobrze rozwiązywał ścieżki podane dla requirejs i po kliknięciu na ścieżkę z CRTL’em przenosił mnie do wybranego pliku? Może to, że łatwo integrował się z narzędziami typu JSLint i JSHint, podświetlając od razu w kodzie wszelkie naruszenia reguł. Co więcej? Wtedy nic więcej do szczęścia nie było mi potrzebne.

Po przejściu do Egnyte przetesowałem jeszcze kilka funkcji WebStorma, z których korzystałem sporadycznie. Były to między innymi:

  • integracja z JIRĄ i logowanie czasu pracy spędzonego w edytorze,\
  • RUN, czyli odpalanie testów poprzez kliknięcie na zieloną strzałkę przy teście.

W sumie to z tej drugiej opcji dosyć często korzystałem.

A może by tak spróbować czegoś nowego?

Wszystkie te funkcje, z których korzystałem, to tylko wierzchołek góry lodowej… tylko ułamek, tego co potrafi WebStorm. W życiu nie użyłem integracji z VCS (git, svn), a podobno pięknie podświetla diffy. Nigdy nie skorzystałem z odpalania skryptów npm czy yarn z poziomu IDE. Pomijając fakt, że o wielu innych funkcjach pewnie nawet nie mam pojęcia…

Pomyślałem — po co płacić za coś, czego nie wykorzystuję? Co mogę z tym faktem zrobić? Odpowiedzi nasunęły się dwie:

  • stać się lepszym ekspertem od WebStorma i zacząć korzystać ze wszystkich jego dobrodziejstw,
  • spróbować czegoś nowego, najlepiej darmowego i zacząć na nowo.

Wiele dobrych opinii czytałem ostatnio na temat VSCode od Microsoftu. Postanowiłem dać mu szansę i przez miesiąc pisać w nim kod. I wiecie co? Nie zawiodłem się!

Największą zaletą, jaką zauważyłem przy korzystaniu z VSCode, była niespotykana wręcz lekkość w działaniu. Za każdym razem, kiedy pracowałem w WebStormie nad dużym projektem, z wentylatora wydobywał się nieznośny szum. Spowodowane było to indexowaniem plików, które WebStorm przeprowadza, żeby „pracowało się lepiej”. W ogóle produkt od JetBrains, z każdym kolejnym wydaniem, wydaje mi się coraz bardziej „ociężały”. Może to tylko mylne wrażenie. Zupełnie inaczej było gdy odpaliłem produkt Microsoftu.

Na starcie VSCode dostajemy dość ubogi edytor. Próżno w nim szukać integracji z JIRĄ, runnera do testów i innych bajerów. By default mamy tu podświetlanie składni JS, TypeScript, debugger i nakładkę do GIT’a. To wszystko. Tylko tyle i aż tyle. Resztę należy sobie doinstalować samemu, poprzez system rozszerzeń. Wtyczek jest mnóstwo, z resztą wejdźcie na stronę produktu i zobaczcie sami.

Żeby być fair wobec WebStorma, należy tu nadmienić, że on także ma możliwość rozbudowy poprzez wiele pluginów instalowanych z poziomu IDE. Niestety nie da się go okroić z „niepotrzebnych” funkcji, z których nie używamy.

Drugim plusem jest cena, a raczej jej brak. VSCode jest darmowy. Za WebStorma musimy zapłacić w formie abonamentu (miesięcznego bądź rocznego). A jak mówi stara dobra reklama proszku do prania — skoro nie widać różnicy, to po co przepłacać?

VSCode jak Webstorm

Dałem szansę produktowi od Microsoftu. Opłacało się, ale nie obyło się bez dodatkowej konfiguracji i wtyczek. Zobaczcie jak poradziłem sobie z dostosowaniem VSCode tak, aby spełniał moje przyzwyczajenia z WebStorma.

Webpack alias / path resolver

Tak jak wspomniałem na początku, wielkim plusem przy używaniu WebStorma jest fakt, że po kliknięciu na importowaną ścieżkę modułu zostajemy przeniesieni do wybranego pliku. Działa to też znakomicie z webpackiem, w którym mamy zdefiniowane aliasy.

Załóżmy, że nasza struktura projektu wygląda następująco:

I chcemy teraz w naszym, specyficznym dla modułu, komponencie użyć generycznego Buttona z folderu components.

Można to zrobić na dwa sposoby:

1. Relative path:

2. Alias w webpacku:

WebStorm sam ogarnie, że mamy konfigurację webpacka i na jej podstawie będzie rozwiązywał ścieżki do pliku. Kliknięcie z CRTL/CMD na ścieżce spowoduje otworzenie docelowego pliku. Nie musimy nic konfigurować.

Jeśli chodzi o VSCode to pierwsza opcja zadziała bez problemu. Druga niestety nie. Aby to naprawić należy dodać do projektu plik o nazwie jsconfig.json. W nim deklarujemy ustawienia naszego projektu pod kątem JS’a:

Zawartość pliku jsconfig.json

W kontekście rozwiązywania ścieżek, najważniejsze są dla nas pola:

  • baseUrl ustawia ścieżkę bazową,
  • paths, w którym ustawiamy nasz mapping,
  • jsx — bez tego nie zadziała nam przeniesienie do plików .jsx,
  • moduleResolution — bez tego nie zadziała nam opcja przeniesienia bezpośrednio do pliku index, jeśli wskażemy folder import B from „components/Button”.

Od teraz po kliknięciu z klawiszem CRTL/CMD w importowaną ścieżkę zostaniemy automatycznie przeniesieni do docelowego pliku.

Autoclose + autorename tags

Super opcją w WebStormie, którą dostajemy bez dodatkowych pluginów czy konfiguracji, jest automatyczne zamykanie i zmiana nazw tagów. Rzecz bardzo przydatna, jeśli edytujecie HTML’a albo pracujecie z Reactem i składnią JSX.

styled-components

Od niedawna zacząłem stylować aplikację przy pomocy css-in-js. Co prawda używam do tego biblioteki emotion.sh zamiast styled-components, natomiast podejście z wykorzystaniem string-templates jest w obu takie samo. Fakt ten możemy wykorzystać przy podświetlaniu składni, czy auto-uzupełnianiu.

Oba IDE, zarówno WebStorm jak i VSCode, nie wspierają „by default” kolorowania składni ani auto-uzupełniania. Natomiast do obu możemy znaleźć pluginy, które ułatwiają nam codzienną pracę przy pisaniu kodu css-in-js.

Po zainstalowaniu pluginów wszystko działa jak ta lala :).

ESlint

Integracja z ESLintem, też wymaga dodatkowego plugina vscode-es-lint. Tyle, że po instalacji nie musimy niczego konfigurować 🙂 Wykryte problemy wyświetlane są automatycznie. Dodatkowo mamy możliwość skonfigurowania automatycznego naprawiania problemów przy zapisywaniu plików. Wystarczy dodać linijkę „eslint.autoFixOnSave": true, do pliku konfiguracyjnego.

Swoją drogą ustawienia VSCode trzymane są na zasadzie pliku json, więc możecie w każdej chwili wyeksportować je gdzieś i zapisać w razie „w”.

Theme

Nie ukrywam, że jestem wielkim fanem skórki „Dracula”, którą w WebStormie możemy wybrać na „dzień dobry”. Na szczęście ktoś już stworzył taką samą skórkę dla VSCode i udostępnił w ramach łatwo instalowalnej wtyczki dracula-theme.

Keyboard shortcuts

Przy przesiadce z WebStorma na VSCode musiałem nauczyć się kilku nowych, bardzo przydatnych skrótów klawiszowych:

  • CMD + SHIFT + P — otwiera Command Pallete,
  • CMD + P — otwiera File Search, który szuka także np. po skróconych nazwach folderów,
  • CMD + B — toggle sidebar,
  • CMD + J — toggle bottom-bar (terminal/problems),
  • CRTL + SHIFT + ~ — otwiera terminal,
  • CMD + SHIFT + E — otwiera explorera,
  • CMD + SHIFT + X — otwiera okno z pluginami.

Ze starych skrótów został mi:

  • CMD + SHIFT + F — otwiera search panel.

Dodatkowo musiałem zmienić kilka ze swoich przyzwyczajeń.

  • ALT + SHIFT + ARROW_DOWN — duplikacja linii (zamiast CMD + D),
  • CMD + SHIFT + L — zaznacza wszystkie wystąpienia obecnego „zaznaczenia” + stawia multikursor, aby od razu edytować wiele miejsc na raz.

Dodatkowe pluginy

Na razie jestem na etapie poznawania całego ekosystemu VSCode, ale jest jest jeden plugin, który mogę polecić z ręką na sercu: git-lense.

Posiada on bardzo dużo opcji konfiguracyjnych. Świetnie pokazuje diffy, historię i blame. To ostatnie może być wyświetlane wg. aktualnej pozycji kursora!

Jeśli używacie VSCode i znacie jeszcze jakieś fajne wtyczki dajcie znać w komentarzach — chętnie je przetestuję.

Podsumowanie

Z VSCode korzystam od kilku miesiący. Muszę przyznać, że bardzo wygodnie mi się pracuje z tym IDE. Jego największą zaletą w porównaniu do WebStorma jest jego „lekkość” i konfigurowalność. Jeśli nie jesteście przekonani do zmiany, to zobaczcie sobie prezentację, która natchnęła mnie do tej przesiadki.


Artykuł został pierwotnie opublikowany na blogu autora.

Zapraszamy do dyskusji
Nie ma więcej wpisów

Send this to a friend