Jak przesiąść się z płatnego Webstorm’a na darmowy VScode

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.

Zobacz też

Frontend WebAssembly. Moc ukryta w przeglądarce (i nie tylko)

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ę!

Zobacz też

Backend Czy Fullstack ma łatwiej na rynku pracy? Devdebata

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ć?

Oferty pracy z

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:

/components
--/Button
--/Link
/features
--/SomeModule
----/SomeSubModule
------/redux
------/view
-------/SpecificComponentForModule
---------/Component.jsx
webpack.config.js

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:

import Button from "../../../../components/Button";

2. Alias w webpacku:

//webpack config
...
resolve: {
  alias: {
    components: path.join(__dirname, "components")
  }
}
...

// Component.jsx
import Button from "components/Button";

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

{
    "compilerOptions": {
        "target": "es2018",
        "jsx": "react",
        "allowSyntheticDefaultImports": true,
        "moduleResolution": "node",
        "baseUrl": ".",
        "paths": {
            "components/*": ["./components/*"],
        }
  },
  "exclude": ["node_modules", "target"]
}

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.

• webstorm-styled-components
• vscode-styled-components

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.