Terminal jako moje IDE do pracy z Node.js (neovim btw)#

Moja historia była prosta. Przyszedłem do Linuksa z innego systemu operacyjnego (nieważne którego) i nie chodziło tu o samą dystrybucję Linuksa. Byłem wyposażony w IDE (VS Code). Decyzja o tej zmianie była podyktowana czynnikami takimi jak: chęć posiadania środowiska deweloperskiego możliwie blisko produkcyjnego serwera, nawet jeśli środowisko deweloperskie nie jest w pełni skonteneryzowane, osobista ciekawość i potrzeba używania Linuksa na co dzień jako głównego systemu, obietnica płynnej personalizacji i wiele innych. Ten wybór mnie nie zawiódł, a co więcej pozwolił mi wejść głębiej w ten temat, szukając narzędzi kompatybilnych z tym systemem, i jak możesz się domyślić, zmierzyłem się na Neovim'em + TMUX'em, gdzie „zmierzyłem się” jest chyba najlepszym słowem, by opisać odkrycie akurat tej konkretnej rzeczy. To pokazało mi, że nie tylko sam komputer jako maszyna czy system mogą być bardziej zoptymalizowane i efektywne, ale że istnieją też narzędzia, które pomagają być bardziej produktywnym jako twórca i power user, a do tego dają pełną kontrolę nad nimi. Trochę dostroiłem też to środowisko tak, żeby dobrze działało dla mnie jako developera Node.js. AI też dobrze wpisuje się w ten setup: jest sporo agentów działających w terminalu i dobrze współgrają one z resztą narzędzi, dając mi szybkie generowanie kodu, szybkie poruszanie się po kodzie i sprawne przełączanie kart. Przejdźmy więc głębiej do głównych narzędzi, których używam w swoim workflow.

Edytor tekstu#

Według State of JS 2025 użycie Neovim wśród devów JS wynosiło 3%. Vim miał lepszy wynik — 20%. Neovim jest forkiem Vima, wykorzystującym vim motions, modalny styl pisania złożony z trybów takich jak insert do pisania, normal do zarządzania edytorem, visual do zarządzania zaznaczeniem i tekstem, i wielu innych. Kiedy dawałem Neovimowi szansę, nie wiedziałem nic o jego popularności, więc po jakimś czasie używania zaskoczyło mnie, że to narzędzie jest u nas aż tak niszowe. To, co przyciągnęło mnie do Neovim, to idea używania wyłącznie klawiatury do programowania bez kompromisów przy: pisaniu, zarządzaniu oknami, kopiowaniu kodu, szybkim przeskakiwaniu między plikami i referencjami, a jednocześnie z możliwościami podobnymi do VS Code, jak fuzzy search, debugger i sensowne wsparcie dla TypeScript'a. Ta potrzeba wynikała z mojej chęci poprawy skupienia w pracy i pozbycia się rozpraszaczy. Poza samym pisaniem jest tu też schludny interfejs tak schludny, jaki potrzebuję. Bez ton powiadomień, ikon, okien i mozolnych animacji, wszystkiego, co ma sprawiać, że edytor wygląda atrakcyjnie wizualnie, ale w moim przypadku psuje DX i kradnie moje skupienie.

Z perspektywy JavaScript'a/TypeScript'a mam porządny LSP, który daje mi szybkie i precyzyjne podpowiedzi w kodzie, pozwalając płynnie przeskakiwać od referencji do referencji. Do LSP używam pmizio/typescript-tools.nvim, czyli pełnego zestawu narzędzi dla TypeScript'a, który pozwala mi używać Neovim nawet w dużych projektach bez spadku wydajności, ale najpiękniejsze jest to, że mogę zmienić integracje LSP, kiedy tylko chcę, albo nawet napisać własną swoją.

Ergonomia pisania i przeskakiwanie po kodzie to świetne połączenie, które zwiększa nie tylko produktywność, ale też skupienie. Rozdzielenie na tryby pozwala wykonywać atomowe operacje na tekście. Dla devów JS zaznaczanie obiektów tekstowych to prawdziwy booster. Używając flash, możesz teleportować się w dowolne miejsce w pliku, a przewijanie oparte wyłącznie na klawiaturze też jest świetne współgra bardzo dobrze z Neovim'mem. Bardzo dobre jest też to, że możesz używać vim motions w innych edytorach, takich jak VS Code czy WebStorm, za pomocą dedykowanych pluginów.

Dla mnie, jako full-stack deva i jednocześnie użytkownika Linuksa, terminal zajmuje 80% mojego czasu developmentu. W takiej sytuacji, gdy używam Neovim'a mogę, szybko go otworzyć i zacząć przeglądać albo edytować kod. Najważniejsze jest to, że Neovim żyje w terminalu, w przeciwieństwie do VS Code, który uruchamia wbudowany w niego terminal, i to wydaje mi się dziwne, problematyczne, a do tego dużo wolniejsze.

Biorąc pod uwagę wsparcie LSP, vim motions, elastyczność, swobodę personalizacji, rozmiar i szybkość, Neovim zostawia popularne opcje IDE daleko, daleko w tyle.

Czego nie lubię w Neovim'ie? Jest tylko jedna taka rzecz, czyli debugger. Generalnie Neovim jest w pełni funkcjonalny i ma wsparcie dla debug adaptera, ale początkowa konfiguracja potrafi być trudna, a samo doświadczenie nie jest tak dopracowane jak w innych, w pełni rozwiniętych edytorach opartych na IDE. W VS Code mamy możliwość zamienić prawie każdą część edytora w maszynę do debugowania, gdzie możemy analizować kod bezpośrednio w pliku, a nie tylko w oknach przeznaczonych do debugowania. Debugger jest generalnie czymś bardziej pod klikanie niż poruszanie się wyłącznie klawiaturą. Mój styl debugowania mocno opiera się na debuggerze, więc ten aspekt jest dla mnie niewygodny, ale mimo to, to jest to dla mnie niewielka cena.

Zarządzanie oknami, kontekstem i zakładkami#

W poprzedniej sekcji wspomniałem, że Neovim żyje w terminalu. To sprawia, że łatwo otworzyć go w konkretnym miejscu i w każdej sytuacji przeczytać, co tylko chcesz, szybko otworzyć go, żeby coś napisać, a potem go zamknąć. Ale w codziennej pracy trzeba mieć otwartych jeszcze kilka zakładek albo nawet mieć dwa edytory otwarte na raz, a często używa się też więcej niż dwóch terminali, które w małych okienkach zagnieżdżonych w aplikacji desktopowej są po prostu nie do ogarnięcia. Bardzo trudno szybko się przez nie przeklikać i sprawnie między nimi przeskakiwać, szczególnie teraz, gdy czasem chcemy mieć w terminalu otwartych kilka agentów naraz. Rozwiązaniem tego problemu jest TMUX.

TMUX to multiplekser terminala, który pozwala dzielić terminal poziomo i pionowo, a także tworzyć osobny panel dla każdej nowej instancji terminala i zarządzać nimi za pomocą skrótów klawiaturowych, wszystko w ramach jednej sesji i jednego emulatora terminala. Każda akcja jest wywoływana unikalną kombinacją klawiszy zwaną prefix'em, która w moim przypadku to Ctrl + A. Na przykład gdy chcę utworzyć nową zakładkę, szybko wciskam Ctrl + A, potem C, i nowa zakładka zostaje utworzona. Kiedy chcę przeskoczyć do innej, wciskam Ctrl + A i numer zakładki, na przykład 2.

TMUX w parze z Neovim to zabójczo dobry duet. Sam Neovim też ma splity, więc możesz używać ich wewnątrz zakładek TMUX-a. Wyobraź sobie, że pracujesz nad kilkoma serwisami, np. serwerem, klientem i jakimś workerem, i musisz przeskakiwać między całą trójką, gdy wszystkie działają jednocześnie. W praktyce chcesz mieć otwartego Neovim w trzech miejscach i trzy terminale, w których możesz je uruchamiać. Możesz bardzo szybko to spiąć, trzymając jeden edytor na serwis w osobnych zakładkach i przeskakując między nimi natychmiast, nawet bez dotykania myszki. W świecie Node.js taki scenariusz jest bardzo częsty, a kiedy dorzucisz do tego testy, potrzebujesz jeszcze więcej terminali. Z TMUX-em da się tym zarządzać piekielnie szybko: wszystko dzieje się w jednym emulatorze terminala, bez problematycznego przełączania się między instancjami emulatora albo, co gorsza, przeklikiwania się przez instancje IDE i te małe okienka, w których osadzone są terminale.

Jeszcze jedna rzecz, pozornie mała, ale czasem bywa nieoceniona dla komfortu pracy, jest taka, że sesję TMUX można bardzo łatwo przywrócić. Oznacza to, że kiedy zamkniesz emulator terminala, twoja praca nie znika. Możesz otworzyć go ponownie, wpisać tmux a, i wszystko wróci. Wszystkie zakładki i procesy będą z powrotem, bo serwer tmux cały czas działa w tle.

Zarządzanie kontrolą wersji#

Używam gita jako systemu kontroli wersji. Jak wiadomo, domyślnym sposobem zarządzania gitem jest terminal. Często opcje GUI są szybsze i nie ma sensu wpisywać komend git do wszystkiego, ale ponieważ mój workflow siedzi w całości w terminalu, nie ma tu miejsca na GUI. Ale... jest coś takiego jak TUI, terminal user interface. Dlatego do większości zadań związanych z gitem, takich jak commit, merge, pull/push, przeglądanie diffów, poruszanie się po commitach czy zarządzanie worktree, używam aplikacji TUI o nazwie lazygit. Jest też plugin do Neovim (gitsigns), który ogarnia staging bezpośrednio z poziomu kodu, pokazywanie diffów, git blame i tak dalej.

Jeśli chodzi o lazygit, jeszcze jedna rzecz, która jest dla mnie wygodna, to fakt, że nawigacja w nim działa w stylu Vim, co oznacza, że mogę poruszać się w górę, w dół, w lewo i w prawo za pomocą hjkl. Ten zestaw klawiszy zastępuje strzałki i nie jest moim własnym, niestandardowym układem, tylko konwencją, która utrzymała się głównie po to, żeby trzymać ręce w centralnej części klawiatury używanej do pisania.

Zarządzanie plikami#

Mogło by się powiedzieć: kto chce zarządzać plikami, hurtowo kopiować, usuwać, zmieniać nazwy, sortować, wyszukiwać i filtrować, używając wyłącznie komend terminalowych? To prawda, pewnie nikt. Ale jest narzędzie, które świetnie się do tego nadaje, a jednocześnie pozwala zostać w pełni wewnątrz terminala. Ta aplikacja TUI ma zabawną nazwę: yazi. yazi to aplikacja TUI, która korzysta z vim motions i nawigacji w stylu Vim, co pozwala mi płynnie przechodzić od terminala do zarządzania plikami bez przestawiania sobie w głowie mapy skrótów i bez dotykania myszki. Do tego dobrze wygląda, po prostu estetyczna lista plików, która pozwala poruszać się poziom po poziomie, sortować, filtrować i wiele wiele więcej.

A co z AI?#

Przetestowałem sporo różnych rozwiązań AI, od wczesnych narzędzi do autouzupełniania, takich jak Tabnine, przez nowoczesne IDE wspierane przez AI, takie jak VS Code, Cursor i Windsurf, aż po terminalowych agentów CLI, takich jak Claude Code, GitHub Copilot CLI i OpenCode. Na szczęście dla mnie to właśnie rozwiązania terminalowe wydają się najlepsze. Więc nawet w tym przypadku nie muszę wychodzić z terminala i nadal mając możliwość organizować wszystko w TMUX'ie.

Na ten moment moim osobistym wyborem, jeśli chodzi o rozwiązanie agentowe w terminalu, jest OpenCode. Wyróżnia się przejrzystością TUI i UX-em, a także możliwością korzystania z niemal każdego dostawcy modeli, jakiego chcę, co daje mi swobodny wybór spośród ogromnej większości modeli i opcji cenowych.

OpenCode ma wszystko, czego potrzeba do nowoczesnego workflow agentów AI, takie jak subagenci, agenci, skille, wsparcie dla MCP i tak dalej. Ma też integrację z Neovim za pośrednictwem pluginu opencode.nvim.

Jeśli chodzi o autouzupełnianie kodu, to obecnie nie używam żadnego z tych narzędzi, tylko samego Neovim'a. Przez większość czasu czytam i poprawiam kod, a kiedy muszę pisać go ręcznie, vim motions w zupełności mi wystarczają.

Podsumowanie#

Prostota, możliwość personalizacji i wolność działają w moim przypadku. Nie marnuję zasobów na świecidełka, a mój system developerski jest wolny od telemetrii. Mam poczucie, że używam narzędzi, które dobrze ze sobą współgrają, dzielą to samo podejście do nawigacji opartej na klawiaturze i trzymają mnie w tym samym kontekście niezależnie od tego, czy piszę komendy CLI, koduję, promptuję, czy zarządzam plikami. Mam też pełną kontrolę nad całym swoim setupem. Jasne, są pewne trade-offy. Kiedy masz tyle przestrzeni na personalizację i kontrolę, musisz poświęcić trochę czasu na skonfigurowanie swojego środowiska i jest mnóstwo okazji, żeby coś popsuć. Ale można używać gita do śledzenia zmian w swoich konfiguracjach, co pomaga rozwijać i przeorganizowywać swoje osobiste IDE z większą pewnością.

Moja droga i fascynacja vim motions oraz całą tą otoczką są doskonałym przykładem tego, że czasem powrót do korzeni może być najlepszym ruchem, chociaż, szczerze mówiąc, nie byłem jeszcze zawodowo aktywny w czasach szczytowej popularności Vima.

Jeśli kiedykolwiek zastanawiałeś się, czy open source'owe oprogramowanie, takie jak Neovim i cała otoczka wokół niego, może pokonać w pełni wyposażone, gotowe do użycia, wspierane przez AI IDE, to mogę Cię zapewnić, że tak.

A jak wygląda Twój setup?