Oxc: nowa generacja narzędzi dla JavaScript i TypeScript
Oxc to zestaw narzędzi dla JavaScript i TypeScript napisany w Rust, który sprawdza, formatuje i przetwarza kod wielokrotnie szybciej niż ESLint, Prettier czy Babel. Wyjaśniamy, z czego się składa, ile czasu realnie oszczędza i kiedy zmiana narzędzi w projekcie ma sens.
W wielu firmowych projektach programista po zapisaniu pliku czeka, aż edytor skończy sprawdzać kod, a potok CI przy każdej zmianie spędza kilka minut na tej samej kontroli. Nikt nie ma tego w budżecie. A jednak to się sumuje. Oxc to zestaw narzędzi dla JavaScript i TypeScript napisany w języku Rust, który wykonuje tę samą pracę co ESLint, Prettier czy Babel, tyle że kilkadziesiąt razy szybciej. Szybkość to nie jedyny powód, dla którego Oxc trafił do projektów Shopify, Airbnb czy zespołu rozwijającego Vue.js. Projekt porządkuje coś, co przez lata rosło chaotycznie: kilka niezależnych narzędzi, z których każde osobno czyta i analizuje ten sam kod. W projektach pisanych w TypeScript to podwójnie odczuwalne, bo kontrola typów sama w sobie jest kosztowna.
Poniżej opisujemy, z czego składa się Oxc, co mówią liczby, gdzie narzędzia wciąż mają luki i jak podchodzimy do ich wdrażania w istniejących projektach. Tekst jest dla osób, które decydują o projekcie, a nie muszą znać każdego polecenia w terminalu.
Czym jest Oxc i kto za nim stoi
Nazwa pochodzi od JavaScript Oxidation Compiler. „Oksydacja” to w środowisku programistów żartobliwe określenie przepisywania narzędzi na Rust („rust” po angielsku znaczy rdza). Język Rust kompiluje się do kodu maszynowego i pilnuje bezpiecznego korzystania z pamięci, dzięki czemu programy w nim napisane są szybkie i stabilne, a do tego potrafią wykorzystać wszystkie rdzenie procesora.
Oxc jest projektem open source na licencji MIT, rozwijanym przez firmę VoidZero i społeczność. VoidZero założył Evan You, twórca Vue.js i Vite, a jego celem jest jeden spójny zestaw narzędzi dla całego ekosystemu JavaScript. Oxc jest w tej układance fundamentem: dostarcza elementy, na których działają kolejne narzędzia tej samej firmy. Za projektem stoi więc zespół zatrudniony przez firmę, a nie jeden hobbysta po godzinach. Przy narzędziu, z którym projekt będzie żył latami, to mocny argument.
Dlaczego dotychczasowe narzędzia zwalniają w dużych projektach
Typowy projekt frontendowy korzysta z kilku narzędzi pomocniczych. Linter wyłapuje błędy i odstępstwa od przyjętych zasad, zanim kod trafi do użytkowników. Formatter ujednolica wygląd kodu, żeby wszyscy w zespole pisali w tym samym stylu. Transpiler tłumaczy TypeScript i nowoczesną składnię na kod, który rozumie przeglądarka, a bundler skleja setki plików w paczkę gotową do wdrożenia.
Najpopularniejsze z tych narzędzi - ESLint, formatter Prettier i Babel - napisano w samym JavaScripcie. Powstawały, gdy projekty liczyły kilkaset plików, a nie kilkadziesiąt tysięcy. Działają w dużej mierze na jednym wątku procesora i każde z nich osobno zamienia ten sam plik tekstowy na wewnętrzną strukturę, na której pracuje. W małym projekcie to bez znaczenia. W monorepo z kilkoma aplikacjami sprawdzenie całego kodu potrafi trwać minuty, a w skrajnych przypadkach nie kończy się wcale, bo proces wyczerpuje pamięć.
Pierwsze próby rozwiązania tego problemu już były. Narzędzie Biome połączyło linter i formatter w jednym programie napisanym w Rust. Oxc idzie podobną drogą, ale kładzie większy nacisk na zgodność z tym, czego zespoły już używają.
Z czego składa się Oxc?
Oxc to nie jeden program, tylko rodzina narzędzi. Dwa z nich programiści widzą na co dzień, pozostałe pracują w tle, wewnątrz innych narzędzi.
Oxlint, czyli linter
Oxlint osiągnął wersję 1.0 w czerwcu 2025 r. Według zapowiedzi stabilnej wersji Oxlint zawierał wtedy ponad 500 reguł znanych z ESLint i popularnych wtyczek (React, Jest, importy) i działał 50-100 razy szybciej od ESLint. Nie wymaga konfiguracji na start, więc da się go uruchomić w istniejącym projekcie w kilka minut.
W 2026 r. doszły dwie ważne rzeczy. W marcu pojawiły się wtyczki JavaScript w wersji alfa, dzięki którym Oxlint uruchamia istniejące wtyczki ESLint bez przepisywania. W lipcu ustabilizowano analizę opartą na typach TypeScript: 59 z 61 reguł typescript-eslint korzystających z informacji o typach działa 12-18 razy szybciej niż w ESLint. To reguły, które łapią najbardziej podstępne błędy, na przykład nieobsłużone operacje asynchroniczne.
Oxfmt, czyli formatter
Oxfmt jest młodszy. Wersja alfa wyszła w grudniu 2025 r., beta w lutym 2026 r. Twórcy podają, że w wersji beta Oxfmt przechodzi 100% testów zgodności z Prettierem dla JavaScript i TypeScript i jest ponad 30 razy szybszy od niego. Formatuje też JSON, YAML, CSS, HTML, Markdown i GraphQL, sortuje importy oraz klasy Tailwind CSS.
Zgodność z Prettierem waży tu więcej niż szybkość. Oznacza, że zmiana formattera nie przemebluje całego kodu i nie zasypie historii zmian tysiącami przesunięć spacji.
Parser, transformer, minifier i resolver
Pozostałe części Oxc pracują pod maską innych narzędzi:
parser zamienia tekst programu w drzewo składniowe, czyli strukturę, na której pracują wszystkie pozostałe narzędzia,
transformer przerabia TypeScript i JSX na zwykły JavaScript,
minifier zmniejsza kod wysyłany do przeglądarki,
resolver ustala, do którego pliku prowadzi każdy import.
Parser jest tu fundamentem. Parsery w JavaScript stoją na początku każdego narzędzia do analizy kodu, więc od ich tempa zależy tempo wszystkiego, co dzieje się dalej. Oxc ma jeden szybki parser, z którego korzystają wszystkie jego części. Dla firmy istotniejsze jest to, gdzie te elementy już pracują. Korzysta z nich Rolldown, nowy bundler, na którym od marca 2026 r. opiera się Vite w wersji 8.
Oficjalna wtyczka Reacta dla Vite używa transformera Oxc i nie potrzebuje już kompilatora Babel, który przez lata był w tym miejscu standardem. Wiele zespołów korzysta więc z Oxc, nawet o tym nie wiedząc. Wystarczy, że zaktualizowały Vite.
Oxc, ESLint, Prettier i Biome - czym się różnią w praktyce
ESLint pozostaje standardem z największym ekosystemem wtyczek i najbogatszą dokumentacją. Jeśli projekt ma dziesiątki własnych reguł, pisanych pod konkretne potrzeby firmy, ESLint nadal jest najpewniejszym miejscem do ich uruchamiania. Oxlint może z nim współpracować: osobna wtyczka wyłącza w ESLint te reguły, które sprawdza już Oxlint, więc oba narzędzia nie dublują pracy. Biome to najbliższy odpowiednik Oxc. Jeden program łączy linter i formatter, konfiguracja jest prosta, a od wersji 2 Biome sam wnioskuje typy TypeScript. Według analizy InfoQ łapie w ten sposób około 75% przypadków, które wykrywają reguły korzystające z pełnego kompilatora TypeScript. Oxlint korzysta z oficjalnego kompilatora TypeScript 7 napisanego w Go, dzięki czemu jego wyniki pokrywają się z typescript-eslint.
Różnica sprowadza się do filozofii. Biome buduje własny, spójny świat. Oxc stara się wiernie odtworzyć zachowanie ESLint i Prettiera, więc przejście na niego jest mniej rewolucyjne dla projektu, który od lat żyje w tamtym ekosystemie.
Gdzie Oxc ma jeszcze luki
Oxlint jest stabilny, ale nie wszystko wokół niego. Oxfmt we wrześniu 2026 r. wciąż ma numer wersji zaczynający się od zera i status bety. Działa dobrze na typowym kodzie JavaScript i TypeScript, jednak z plikami Astro czeka na obsługę wtyczek Prettiera, a Svelte wymaga dodatkowej konfiguracji. Większe ograniczenie dotyczy projektów na Vue, Svelte i Angularze. Według tabeli zgodności Oxlint i Oxfmt Oxlint nie sprawdza jeszcze szablonów tych frameworków, czyli części komponentu z kodem HTML. Skrypty sprawdzi, szablony trzeba zostawić ESLintowi.
Analiza oparta na typach wymaga TypeScript 7. Projekt na starszej wersji albo z przestarzałymi ustawieniami kompilatora najpierw musi przejść aktualizację. Do tego dochodzi tempo zmian: nowe wersje Oxlint wychodzą co tydzień. Dla zespołu oznacza to przypięcie konkretnej wersji w projekcie i świadome aktualizacje zamiast automatycznych.
Najwięcej zyskują projekty duże i długo rozwijane. Monorepo z kilkoma aplikacjami, kod liczony w dziesiątkach tysięcy plików, CI, w którym lintowanie jest jednym z najwolniejszych kroków. Tam różnica jest odczuwalna od pierwszego dnia, a oszczędność kumuluje się z każdym sprintem. W małym projekcie, gdzie ESLint kończy pracę w kilka sekund, zysk z szybkości będzie niewielki. Oxc nadal może mieć sens, bo upraszcza konfigurację i zmniejsza liczbę zależności, ale to nie powód, żeby rzucać bieżącą pracę.
Z decyzją lepiej poczekać, jeśli projekt mocno opiera się na szablonach Vue lub Angulara, używa wielu własnych wtyczek ESLint albo działa na starszej wersji TypeScript. W takiej sytuacji rozsądniej jest dopisać zmianę narzędzi do planu spłaty długu technologicznego i wrócić do niej, gdy Oxfmt wyjdzie z bety, a wtyczki JavaScript okrzepną.
Starsze projekty mają często inny problem niż wolny linter, na przykład przestarzały bundler webpack z konfiguracją, której nikt już nie rozumie. Wtedy przejście na Vite 8 daje Oxc „w pakiecie”, razem z szybszym budowaniem aplikacji. To większy projekt, ale też większy zysk. Nowe projekty w web developmencie można zaczynać od Oxlint i Oxfmt bez wahania, o ile zespół akceptuje status bety formattera. Konfiguracja zajmuje tyle samo czasu co w przypadku ESLint i Prettiera, a za rok nie trzeba będzie przeprowadzać migracji.
Jeśli zastanawiasz się, czy w Twoim projekcie zmiana ma sens i ile czasu realnie odzyska zespół, porozmawiajmy o Twoim projekcie. Zaczniemy od pomiaru obecnych czasów.
FAQ
FAQ - Najczęściej zadawane pytania o Oxc
Tak, wszystkie narzędzia Oxc, w tym Oxlint i Oxfmt, są udostępnione na licencji MIT i można ich bez opłat używać w komercyjnych, zamkniętych projektach. Licencja MIT pozwala korzystać z kodu, modyfikować go i dołączać do własnego oprogramowania, a jedynym wymogiem jest zachowanie informacji o autorach i licencji. Nie ma płatnej wersji Oxlint ani Oxfmt z dodatkowymi funkcjami, a Vite+, czyli zbiorczy zestaw narzędzi firmy VoidZero, również jest na licencji MIT. Realnym kosztem jest więc wyłącznie czas zespołu poświęcony na konfigurację, migrację reguł i aktualizacje. Jego wysokość zależy od wielkości projektu i tego, jak rozbudowana była dotychczasowa konfiguracja ESLint i Prettiera.
Tak, Oxlint i ESLint mogą działać w jednym projekcie jednocześnie i jest to najczęściej polecany sposób rozpoczęcia migracji. Do ESLint dodaje się wtedy wtyczkę eslint-plugin-oxlint, która automatycznie wyłącza reguły obsługiwane już przez Oxlint, dzięki czemu ten sam problem nie jest zgłaszany dwa razy. W praktyce polecenie sprawdzające kod najpierw uruchamia Oxlint, który w ułamku sekundy wyłapuje większość błędów, a potem ESLint z regułami, których Oxlint jeszcze nie ma, na przykład regułami dla szablonów Vue. Taki układ może zostać na stałe albo być etapem przejściowym. Zależy to od tego, ile niestandardowych reguł i wtyczek wykorzystuje projekt.
Orientacyjnie od kilku godzin w małym projekcie do kilku tygodni w dużym monorepo, przy czym większą część tego czasu da się rozłożyć na etapy bez wstrzymywania prac nad produktem. W prostej aplikacji z domyślną konfiguracją ESLint i Prettiera narzędzia migracyjne przenoszą ustawienia automatycznie, a zespół głównie sprawdza wyniki i poprawia skrypty w CI. W średnim projekcie z kilkoma wtyczkami trzeba zwykle kilku dni na porównanie reguł i ustalenie, które z nich zostają. Najdłużej trwa migracja dużego repozytorium z własnymi regułami, analizą typów i wieloma aplikacjami. Czas zależy od liczby niestandardowych reguł, wersji TypeScript, użycia frameworków z szablonami (Vue, Svelte, Angular) oraz od tego, jak szybko zespół uzgodni docelowy zestaw reguł.
Tak, Oxlint ma wbudowane zestawy reguł dla Reacta, hooków, dostępności komponentów JSX oraz osobny zestaw reguł dla Next.js. Włącza się je w pliku konfiguracyjnym .oxlintrc.json, bez instalowania dodatkowych pakietów, jak ma to miejsce w ESLint. Reguły sprawdzają między innymi poprawne użycie hooków, brakujące atrybuty dostępności czy typowe pomyłki w korzystaniu z komponentów Next.js, na przykład obrazków i linków. Dostępne są też eksperymentalne reguły związane z React Compiler. Oxlint nie zmienia natomiast sposobu budowania aplikacji Next.js, więc zysk w takim projekcie dotyczy kontroli jakości kodu, a nie czasu kompilacji.
Tak, w przypadku JavaScript i TypeScript Oxfmt przechodzi komplet testów zgodności z Prettierem, więc po zmianie formattera kod wygląda praktycznie tak samo. Twórcy potwierdzili ten wynik w wersji beta opublikowanej w lutym 2026 r. Oxfmt ma też polecenie, które przenosi ustawienia z pliku konfiguracyjnego Prettiera, oraz wbudowane sortowanie klas Tailwind CSS i importów, do których w Prettierze potrzebne są osobne wtyczki. Różnice mogą pojawić się w projektach korzystających z niestandardowych wtyczek Prettiera, bo Oxfmt jeszcze ich nie obsługuje, oraz w mniej typowych formatach plików. Przed zmianą warto uruchomić Oxfmt na kopii repozytorium i przejrzeć listę zmienionych plików.
Tak, od lipca 2026 r. Oxlint ma stabilną obsługę reguł opartych na typach, realizowaną przez dodatkowy pakiet oxlint-tsgolint. Pakiet korzysta z oficjalnego kompilatora TypeScript 7 i obsługuje 59 z 61 takich reguł znanych z typescript-eslint. Przykładem jest wykrywanie obietnic (Promise), których wynik nie jest nigdzie obsłużony, co w aplikacji może oznaczać po cichu gubione błędy przy zapisie danych. Funkcję włącza się flagą --type-aware. Warunkiem jest projekt działający na TypeScript 7, a analiza typów jest wolniejsza niż zwykłe reguły Oxlint, choć według twórców nadal kilkanaście razy szybsza niż w ESLint.
Tak, Vite od wersji 8, wydanej w marcu 2026 r., używa bundlera Rolldown, który do analizy, przekształcania i minifikacji kodu wykorzystuje komponenty Oxc. Oznacza to, że projekt po aktualizacji do Vite 8 korzysta z parsera i transformera Oxc bez żadnej dodatkowej konfiguracji. Oficjalna wtyczka Reacta dla Vite w wersji 6 zastąpiła Babel transformerem Oxc przy obsłudze odświeżania komponentów w trakcie pracy, co zmniejszyło liczbę zależności. Projekty na Vite 7 i starszych używają jeszcze esbuild i Rollupa. Skala korzyści zależy od wielkości aplikacji i liczby wtyczek, bo część starszych wtyczek Rollupa może wymagać aktualizacji.
Tak, od marca 2026 r. Oxlint obsługuje wtyczki JavaScript z API zgodnym z ESLint, więc reguły pisane dla ESLint można załadować bez przepisywania ich na Rust. Wtyczki wskazuje się w konfiguracji Oxlint, a narzędzie uruchamia je obok wbudowanych reguł. Według testów twórców zgodność obejmuje pełen zestaw wbudowanych reguł ESLint i popularne wtyczki, takie jak react-hooks czy Testing Library. Funkcja ma jednak status alfa, dlatego w projekcie produkcyjnym warto najpierw porównać wyniki Oxlint i ESLint na tym samym kodzie. Reguły w JavaScript działają wolniej niż te wbudowane w Oxlint, więc przy dużej liczbie własnych reguł przyspieszenie będzie mniejsze niż przy samych regułach natywnych.
Utrzymanie spójnego stylu i wysokiej jakości kodu to jedno z największych wyzwań w nowoczesnych projektach programistycznych. Wraz z rozwojem ekosystemu JavaScript i TypeScript deweloperzy coraz częściej muszą korzystać z wielu narzędzi do formatowania i lintowania, co prowadzi do złożonej konfiguracji i potencjalnych konfliktów. Biome powstało jako odpowiedź na te problemy, oferując jedno, szybkie i spójne rozwiązanie typu all-in-one.
Babel to niezbędne narzędzie dla każdego programisty JavaScript - kompilator służący do przekształcania nowoczesnego JavaScript (ES6+) w starsze wersje, które mogą być zrozumiałe dla wszystkich przeglądarek. Jest to klucz do tworzenia bardziej zoptymalizowanego, zgodnego i niezawodnego kodu.
Rosnąca złożoność aplikacji webowych sprawia, że wydajność narzędzi developerskich ma dziś ogromne znaczenie. Turbopack, nowy bundler od Vercela, powstał jako odpowiedź na ograniczenia klasycznych rozwiązań, takich jak Webpack, szczególnie w dużych projektach Next.js. Jego głównym celem jest maksymalne skrócenie czasu startu aplikacji i natychmiastowy hot reload podczas pracy z kodem.
JavaScript oferuje zasoby, które pomagają twórcom kodu lepiej manipulować strukturą danych, z parserami na czele. Co to są parsery, jak działają i w jaki sposób mogą ułatwić pracę każdemu programiście? Rozpoczynamy odkrywanie tajników parserów w języku JavaScript.
CI/CD to skrót od Continuous Integration i Continuous Delivery, czyli procesów ciągłej integracji i ciągłego dostarczania. Jest to metoda zarządzania projektem oprogramowania, która polega na ciągłym i automatycznym sprawdzaniu, testowaniu i wdrażaniu kodu do produkcji.
Każdy programista dąży do perfekcji. To idealne podejście do kodowania oznacza skupienie na jakości. Jakość kodu zależy od wielu czynników, wliczając w to przejrzystość, zrozumiałość i łatwość utrzymania. Właśnie tutaj Pre-Code Review i Code Review wchodzą do gry. W artykule poruszymy sekrety, które pomogą poprawić jakość Twojego kodu.
