Biome, formater i linter w jednym narzędziu

Biome, formater i linter w jednym narzędziu

Biome to napisany w Rust program, który formatuje kod i sprawdza go statycznie, zajmując w projekcie miejsce pary ESLint plus Prettier. Bieżąca wersja to 2.5.9 z 17 sierpnia 2026 roku, repozytorium biomejs/biome ma około 25,6 tysiąca gwiazdek, a licencja jest podwójna: MIT albo Apache 2.0, do wyboru odbiorcy.

Co Biome właściwie robi

W jednym pliku wykonywalnym siedzą trzy osobne funkcje i rozróżnienie ich od siebie oszczędza sporo zamieszania przy konfiguracji.

Pierwsza to formater. Odpowiada dokładnie temu, co robi Prettier: bierze poprawny składniowo plik i wypisuje go od nowa według ustalonych reguł łamania linii. Druga to linter, czyli analiza statyczna szukająca błędów i niepożądanych wzorców, z osobnym zestawem reguł i osobnym włącznikiem. Trzecia nazywa się assist i obejmuje akcje porządkowe, które nie są ani formatowaniem, ani zgłaszaniem błędów: sortowanie importów, sortowanie kluczy w obiektach, usuwanie zduplikowanych klas CSS. W wersji pierwszej sortowanie importów było polem najwyższego poziomu, w drugiej przeniosło się do sekcji assist.actions.source.organizeImports i to jest najczęstsza przyczyna tego, że przepisana konfiguracja nagle przestaje działać.

Do tego dochodzi serwer języka, uruchamiany przez biome lsp-proxy albo przez wtyczkę do edytora, oraz demon działający w tle, który trzyma zaindeksowany stan projektu.

Zakres języków jest węższy, niż sugeruje hasło o narzędziu dla całego frontendu. Pełne wsparcie mają JavaScript w wersji ES2024, TypeScript w wersji 5.9, JSX, JSON i JSONC, CSS oraz GraphQL. Pliki Vue, Svelte i Astro obsługiwane są od wersji 2.3.0, ale wprost oznaczone jako eksperymentalne i wymagają włączenia przez html.experimentalFullSupportEnabled. SCSS, YAML i Markdown są w trakcie prac i dziś nie działają. Jeśli w repozytorium formatujesz Prettierem pliki YAML z definicjami procesów w systemie ciągłej integracji, Biome ich nie przejmie.

Czego Biome nie robi, jest równie istotne. Nie sprawdza typów, więc tsc --noEmit zostaje w potoku. Nie uruchamia testów, od tego jest Vitest. Nie buduje aplikacji, bo to zadanie dla Vite. Nie zarządza pamięcią podręczną w monorepozytorium, czym zajmuje się Turborepo.

Wersja, licencja i stan projektu

Wydania wychodzą regularnie i gęsto. Wersje od 2.5.1 do 2.5.9 ukazały się między 23 czerwca a 17 sierpnia 2026 roku, czyli mniej więcej co tydzień. Ostatnia zmiana w gałęzi głównej pochodzi z 20 sierpnia 2026 roku, repozytorium nie jest zarchiwizowane, ma 1196 rozgałęzień i 534 otwarte zgłoszenia.

Z licencją wiąże się rozbieżność, którą łatwo źle odczytać podczas audytu zależności. Pole license w rejestrze npm dla pakietu @biomejs/biome ma wartość MIT OR Apache-2.0. Opublikowana paczka zawiera trzy pliki licencyjne: LICENSE-APACHE, LICENSE-MIT oraz ROME-LICENSE-MIT, czyli tekst MIT z lat 2020-2023 odziedziczony po projekcie Rome, z którego Biome wyrósł. W katalogu głównym repozytorium leżą oba pliki, apacheowy i mitowy. Natomiast interfejs programistyczny GitHuba raportuje dla tego repozytorium jedną licencję, Apache 2.0, bo jego wykrywacz wybiera pojedynczą wartość i nie umie opisać podwójnego wyboru. Stan faktyczny jest taki, że masz do wyboru dowolną z dwóch licencji permisywnych, a narzędzie zbierające metadane z GitHuba pokaże Ci tylko jedną z nich. Jeśli w firmie prowadzisz listę licencji zależności, wpisz tam obie.

Płatnego wariantu nie ma. Strona oznaczona jako Enterprise nie zawiera cennika ani planów, tylko informację, że część współtwórców przyjmuje płatne zlecenia komercyjne, oraz odnośniki do kanału na Discordzie i do formularza zgłoszenia na GitHubie. Finansowanie idzie przez OpenCollective i GitHub Sponsors, a prace nad silnikiem wnioskowania o typach sponsorował Vercel. To układ typowy dla projektu otwartego i niesie znane ryzyko: rozwój zależy od garstki utrzymujących i od pieniędzy sponsorów, a nie od umowy wsparcia, którą można wyegzekwować.

Sposób dystrybucji też ma konsekwencje. Pakiet @biomejs/biome sam w sobie nie ma zależności, ale deklaruje osiem opcjonalnych pakietów z binariami: Linux, macOS i Windows w wariantach x64 i arm64 oraz dwa warianty musl dla Linuksa. Instalacja z flagą pomijającą zależności opcjonalne nie da działającego programu. Pole engines wymaga Node w wersji co najmniej 14.21.3, co w praktyce oznacza brak realnego ograniczenia.

Instalacja i pierwsze uruchomienie

Kolejność poleceń przy wchodzeniu do istniejącego projektu wygląda tak.

# przypięcie dokładnej wersji, nie zakresu
npm install --save-dev --save-exact @biomejs/biome

# wygenerowanie biome.json w katalogu bieżącym
npx biome init

# sprawdzenie bez modyfikacji plików
npx biome check

# formatowanie, reguły naprawialne i akcje assist za jednym razem
npx biome check --write

# to samo z poprawkami oznaczonymi jako niebezpieczne
npx biome check --write --unsafe

# tryb dla serwera budującego: nic nie zapisuje, zwraca kod wyjścia
npx biome ci

# tylko pliki zmienione względem gałęzi głównej
npx biome check --changed --since=main

# dokumentacja pojedynczej reguły prosto z terminala
npx biome explain noFloatingPromises

Flaga --save-exact nie jest przesadą. Wynik formatera bywa dostrajany między wydaniami, a przy zakresie wersji dwie osoby w zespole mogą mieć różne binaria i wzajemnie przeformatowywać sobie pliki. Skoro wydania wychodzą co tydzień, ryzyko jest realne.

Polecenie biome explain przyjmuje nazwę reguły i wypisuje jej grupę, domyślną wagę, rodzaj poprawki, wersję, od której jest dostępna, oraz przynależność do domeny. Dla noFloatingPromises zobaczysz kategorię lint/nursery/noFloatingPromises, domyślną wagę info i poprawkę oznaczoną jako niebezpieczną. To szybszy sposób sprawdzenia stanu reguły niż szukanie jej w dokumentacji.

Konfiguracja w pliku biome.json

Plik biome.json albo biome.jsonc leży w katalogu głównym projektu. Poniżej konfiguracja przetestowana na wersji 2.5.9, bez ostrzeżeń o polach przestarzałych.

{
  "$schema": "https://biomejs.dev/schemas/2.5.9/schema.json",
  "root": true,
  "vcs": {
    "enabled": true,
    "clientKind": "git",
    "useIgnoreFile": true,
    "defaultBranch": "main"
  },
  "files": {
    "includes": ["**", "!**/dist", "!**/coverage"],
    "maxSize": 1048576
  },
  "formatter": {
    "enabled": true,
    "indentStyle": "space",
    "indentWidth": 2,
    "lineWidth": 100,
    "lineEnding": "lf"
  },
  "javascript": {
    "formatter": {
      "quoteStyle": "single",
      "jsxQuoteStyle": "double",
      "semicolons": "asNeeded",
      "trailingCommas": "all",
      "arrowParentheses": "asNeeded"
    }
  },
  "linter": {
    "enabled": true,
    "rules": {
      "preset": "recommended",
      "correctness": {
        "useExhaustiveDependencies": "error",
        "noUnusedImports": "error"
      },
      "suspicious": {
        "noExplicitAny": "warn"
      },
      "style": {
        "useImportType": "error"
      }
    }
  },
  "assist": {
    "enabled": true,
    "actions": {
      "source": {
        "organizeImports": "on"
      }
    }
  },
  "overrides": [
    {
      "includes": ["**/*.test.ts", "**/*.test.tsx"],
      "linter": {
        "rules": {
          "suspicious": { "noExplicitAny": "off" }
        }
      }
    }
  ]
}

Kilka szczegółów z tego pliku zasługuje na komentarz. Pole preset przyjmuje wartości recommended, all albo none i zastąpiło dawne recommended: true, które w wersji 2.5.9 wciąż działa, ale zgłasza ostrzeżenie o wycofaniu i zniknie w kolejnym wydaniu głównym. Wzorce w files.includes używają wykrzyknika jako negacji, przy czym katalog wyklucza się zapisem !**/dist, a nie !**/dist/**. Ta druga forma była obejściem błędu z wersji sprzed 2.2.0 i dziś sam Biome zgłasza ją regułą useBiomeIgnoreFolder. Ustawienie vcs.useIgnoreFile sprawia, że narzędzie honoruje .gitignore, czego nie robi domyślnie.

Domyślne wcięcie to tabulator, a domyślne cudzysłowy to podwójne. Jeśli projekt stał wcześniej na Prettierze ze spacjami, ustaw indentStyle jawnie albo włącz useEditorconfig, inaczej pierwsze uruchomienie przepisze całe repozytorium.

W monorepozytorium każdy podprojekt może mieć własny plik konfiguracyjny, ale musi być oznaczony jako niekorzeniowy przez "root": false. Skrót "extends": "//" ustawia to samo i dodatkowo dziedziczy ustawienia z konfiguracji korzeniowej. Bez tego oznaczenia Biome potraktuje podkatalog jako osobny projekt.

Domeny, czyli reguły włączane przez zależności

Domeny to mechanizm, który odróżnia Biome od klasycznego układu z listą wtyczek. Zamiast instalować eslint-plugin-react i dopisywać go do konfiguracji, włączasz domenę react, a reguły przeznaczone dla tej biblioteki stają się aktywne.

{
  "linter": {
    "domains": {
      "react": "recommended",
      "next": "recommended",
      "test": "recommended",
      "tailwind": "all",
      "project": "recommended",
      "types": "none"
    }
  }
}

Domen jest piętnaście: astro, drizzle, react, reactNative, test, solid, next, qwik, svelte, vue, project, tailwind, turborepo, playwright i types. Każda przyjmuje wartość recommended, all albo none.

Bez jawnego wpisu domena włącza się sama, gdy w pliku package.json znajdzie się odpowiednia zależność. Progi są konkretne: react od wersji 16, next od 14, tailwindcss od 3, turbo od 1, drizzle-orm od 0.9, @playwright/test od 1, a domena test reaguje na jest, mocha, ava lub vitest. Domeny wprowadzają też globalne identyfikatory, dzięki czemu describe i expect w plikach testowych nie są zgłaszane jako nieznane.

Dwie domeny zachowują się inaczej niż reszta i trzeba to wiedzieć, zanim się je włączy. project i types uruchamiają skaner, który indeksuje wszystkie pliki projektu razem z katalogiem node_modules. Do domeny project należą reguły takie jak noUnresolvedImports, noUndeclaredDependencies, noImportCycles i noPrivateImports, czyli dokładnie te, których pojedynczy plik nie wystarczy do sprawdzenia. Domena types dodatkowo uruchamia silnik wnioskowania o typach. Obie kosztują czas i żadna reguła wymagająca skanera nie trafia do zestawu zalecanego poza swoją domeną, co jest świadomą decyzją zespołu na rzecz szybkości.

Jest jeszcze pułapka nazewnicza. W kilku domenach, między innymi tailwind, playwright, astro, drizzle i reactNative, wszystkie reguły siedzą w grupie nursery. Ustawienie wartości recommended nie włączy tam niczego, bo reguły z tej grupy nigdy nie są zalecane. Trzeba użyć all albo wypisać reguły pojedynczo. Dotyczy to na przykład sortowania klas Tailwind CSS, często wskazywanego jako powód, dla którego ktoś zostaje przy ESLint.

Migracja z ESLint i Prettier krok po kroku

Biome ma wbudowane polecenia importujące ustawienia z obu narzędzi i to jest najsensowniejszy punkt startu.

# 1. konfiguracja wyjściowa
npx biome init

# 2. import ustawień formatera
npx biome migrate prettier --write

# 3. import reguł lintera wraz z raportem pokrycia
npx biome migrate eslint --write

# 4. to samo, ale z regułami tylko zainspirowanymi oryginałem
npx biome migrate eslint --write --include-inspired

Raport z kroku trzeciego jest najważniejszą rzeczą w całej migracji, bo mówi wprost, ile zostaje na podłodze. Dla konfiguracji z sześcioma regułami wygląda on tak.

i 6 ESLint rules found
  - 1 have been migrated to Biome's rules
  - 50% (3) of your ESLint rules are fully covered by Biome
    - 16% (1) via direct migration to Biome rules

i Rules that can be migrated to an inspired rule using --include-inspired:
  - max-lines
  - no-magic-numbers

i Unsupported rules (0 incompatible with formatter, 0 made obsolete by the
  formatter, 0 covered by a formatter option, 3 not yet implemented,
  0 unknown source):
  - consistent-return
  - no-warning-comments
  - sort-keys

Podział na kategorie jest przemyślany. Reguły niezgodne z formaterem i reguły przez niego unieważnione możesz spokojnie skreślić, bo Biome i tak wymusza ich efekt. Reguły pokryte opcją formatera przenoszą się do sekcji formatter. Zostaje kategoria „not yet implemented" i to ona jest miarą kosztu migracji.

Kilka rzeczy o samym poleceniu. Nadpisuje ono istniejącą konfigurację i ustawia preset na none, więc po migracji masz dokładnie te reguły, które miałeś w ESLint, i żadnej więcej. Do wczytania konfiguracji płaskiej potrzebuje Node, bo naprawdę uruchamia plik eslint.config.js razem z wtyczkami. Konfiguracji zapisanych w YAML nie obsługuje. Pliki .eslintignore przenosi. Wtyczki i konfiguracje współdzielone eksportujące obiekt z cyklicznym odwołaniem potrafią zatrzymać cały proces, a obejściem jest zakomentowanie ich pojedynczo i powtórzenie migracji.

Dalsza kolejność jest prosta. Przeformatuj całe repozytorium jednym poleceniem biome check --write i zamknij to w osobnym zatwierdzeniu, którego skrót dopiszesz do pliku .git-blame-ignore-revs, żeby nie zepsuć historii zmian. Zaktualizuj wtyczki edytora, bo dwa działające jednocześnie formatery przy zapisie pliku dają wynik zależny od kolejności. Dopiero na końcu usuń zależności ESLint i Prettier, a jeśli któraś wtyczka okazała się nie do zastąpienia, zostaw ESLint z konfiguracją zawężoną wyłącznie do niej.

Czego nie odzyskasz po migracji

Schemat konfiguracji wersji 2.5.9 wymienia 530 reguł lintera w ośmiu grupach: suspicious 121, correctness 100, style 100, nursery 96, complexity 51, a11y 39, performance 16 i security 7. Po odjęciu grupy nursery, która z definicji nie jest zalecana i może się zmienić bez zapowiedzi, zostają 434 reguły gotowe do użycia. To dużo, ale rozkład względem ekosystemu ESLint jest bardzo nierówny.

Oficjalna strona ze źródłami reguł podaje liczby, które warto zobaczyć przed decyzją. Z samego ESLint przeniesiono 106 reguł, z typescript-eslint 44, z eslint-plugin-jsx-a11y 33, ze Stylelint 23, z eslint-plugin-unicorn 21, z eslint-plugin-react 14, z eslint-plugin-jest 7, z @next/eslint-plugin-next 5, z eslint-plugin-import 4, z eslint-plugin-barrel-files 3, a z eslint-plugin-react-hooks, eslint-plugin-sonarjs i eslint-plugin-unused-imports po dwie.

Te liczby czyta się nierówno. Dostępność i podstawowe reguły Reacta są pokryte przyzwoicie. Za to eslint-plugin-import z czterema odpowiednikami wygląda blado, choć część jego roli przejmują reguły domeny project. Najbardziej rzuca się w oczy eslint-plugin-react-hooks z dwoma regułami, useExhaustiveDependencies i useHookAtTopLevel. Reguły związane z kompilatorem Reacta istnieją, ale jako useReactCompiler w grupie nursery.

Reguły wymagające informacji o typach to osobna historia. Silnik wnioskowania Biome działa bez pakietu typescript, co jest sporym osiągnięciem inżynierskim, ale zespół sam podaje, że reguła noFloatingPromises wykrywa około 75 procent przypadków, które złapałby typescript-eslint, i zaznacza, że pomiar jest wstępny i zrobiony na ograniczonym zbiorze. Prawie cała domena types, czyli noMisusedPromises, useAwaitThenable, noBaseToString, noUnsafePlusOperands i pozostałe, siedzi wciąż w grupie nursery. Jeśli w projekcie na TypeScripcie opierasz się na regułach typowanych, to jest miejsce, w którym migracja boli najbardziej.

Na liście źródeł reguł nie ma w ogóle wtyczek takich jak eslint-plugin-jsdoc, eslint-plugin-testing-library, eslint-plugin-storybook czy eslint-plugin-perfectionist. To nie oznacza, że żadna pojedyncza reguła o podobnym działaniu nie istnieje, ale całych zestawów nikt nie przeniósł i nikt tego nie zapowiada.

Zostaje jeszcze warstwa opcji. Dokumentacja zaznacza wprost, że reguły Biome bywają uboższe w opcje od oryginałów. Reguła o tej samej nazwie może więc istnieć, a mimo to nie dać się nastroić tak, jak była nastrojona w ESLint. Nazwy również się różnią, bo Biome używa zapisu camelCase i często zmienia nazwę, żeby lepiej opisać intencję, przez co wyszukiwanie w dokumentacji po starej nazwie zwykle zawodzi.

Wtyczki GritQL zamiast wtyczek w JavaScripcie

Najpoważniejsze ograniczenie architektoniczne wynika z języka implementacji. Skoro Biome jest binarium w Rust, nie da się dołożyć do niego reguły napisanej w JavaScripcie tak, jak dopisuje się wtyczkę do ESLint. Zamiast tego dostajesz GritQL, deklaratywny język dopasowywania wzorców w kodzie.

language js

`console.log($msg)` as $call where {
  register_diagnostic(
    span = $call,
    message = "Użyj console.info zamiast console.log.",
    severity = "warn",
    fix_kind = "safe"
  ),
  $call => `console.info($msg)`
}

Plik z rozszerzeniem .grit podłącza się przez pole plugins, opcjonalnie z zawężeniem do wybranych ścieżek przez includes. Operator => wykonuje przepisanie kodu, przy czym bez flagi --write poprawka jest tylko sugerowana, a poprawki bez jawnego fix_kind traktowane są jako niebezpieczne.

Granice tego rozwiązania są wyraźne. Poza wbudowanymi funkcjami GritQL dostępna jest dokładnie jedna funkcja dodana przez Biome, register_diagnostic, z czterema argumentami. Językami docelowymi są JavaScript, CSS i JSON. Wzorzec nie ma dostępu do wyników wnioskowania o typach ani do grafu modułów. Nie da się też zdefiniować opcji reguły, więc każde zachowanie parametryzowane trzeba zapisać jako osobny plik. Do reguł składniowych obowiązujących w firmie to wystarcza. Do przeniesienia nietrywialnej wtyczki ESLint zwykle nie.

Biome a alternatywy

Wybór rozstrzyga się na dwóch pytaniach. Jeśli Twoja konfiguracja ESLint opiera się na wtyczkach spoza listy przeniesionych albo na regułach typowanych, zostań przy ESLint i co najwyżej oddaj formatowanie Biome, bo to część najbezpieczniejsza i dająca największy zysk czasowy. Jeśli konfiguracja mieści się w regułach podstawowych, w typescript-eslint i w dostępności, jedno narzędzie zamiast dwóch upraszcza potok i skraca krok sprawdzania w Next.js czy w dowolnym innym projekcie do ułamka poprzedniego czasu.

Trzecią drogą jest Oxlint, który z tej tabeli jest najbliższym krewnym: też w Rust, też szybki, ale świadomie tylko lintuje, a formatowanie oddaje osobnemu narzędziu oxfmt. Różni się też modelem wtyczek, bo pozwala pisać je w JavaScripcie zamiast w GritQL, co obniża próg wejścia. Wada jest po drugiej stronie: reguły korzystające z informacji o typach wymagają tam osobnego dodatku i TypeScriptu w wersji 7.0 lub nowszej, więc w projekcie na starszej wersji ta część po prostu nie zadziała.

Typowe błędy

Pierwszy to pozostawienie ESLint, Prettiera i Biome włączonych jednocześnie bez podziału obowiązków. Dwa formatery działające przy zapisie pliku dają wynik zależny od kolejności wtyczek w edytorze, a różnice wracają w każdym zgłoszeniu zmian. Jeśli utrzymujesz oba narzędzia, wyłącz w ESLint wszystko, co dotyczy formatowania.

Drugi to zignorowanie domyślnego wcięcia. Biome domyślnie wcina tabulatorem, Prettier spacjami. Pierwsze uruchomienie biome check --write na repozytorium sformatowanym Prettierem przepisze każdy plik, a wynikowy zbiór zmian będzie nie do przejrzenia.

Trzeci to wzorce wykluczające zapisane po staremu. Zapis !**/dist/** pochodzi z czasów sprzed wersji 2.2.0 i dziś jest zgłaszany regułą useBiomeIgnoreFolder. Poprawna forma to !**/dist.

Czwarty to "recommended": true w sekcji reguł. Pole nadal działa, ale zgłasza ostrzeżenie o wycofaniu i zniknie w następnej wersji głównej. Zastąp je przez "preset": "recommended", a najprościej uruchom biome migrate --write, które przepisze konfigurację samo.

Piąty to włączenie domeny project albo types bez świadomości kosztu. Obie uruchamiają pełny skan projektu razem z node_modules, więc różnica w czasie działania jest odczuwalna. Sensowny układ to trzymać te domeny w potoku ciągłej integracji i wyłączać je w konfiguracji używanej przez edytor.

Szósty to oczekiwanie stabilności od reguł z grupy nursery. Mogą zmienić nazwę, zachowanie albo zniknąć między wydaniami mniejszymi, a wydania wychodzą co tydzień. Jeśli włączasz je jawnie, przypnij dokładną wersję Biome.

Siódmy to nieoznaczone konfiguracje zagnieżdżone. Plik biome.json w podkatalogu bez "root": false albo bez "extends": "//" zostanie potraktowany jako osobny projekt, a reguły korzystające z package.json sięgną do niewłaściwego pliku.

FAQ

Czy Biome zastąpi ESLint w każdym projekcie?

Nie. Zastąpi go tam, gdzie konfiguracja opiera się na regułach podstawowych ESLint, na typescript-eslint i na dostępności. Jeśli korzystasz z wtyczek nieobecnych na liście przeniesionych źródeł albo z reguł wymagających pełnej informacji o typach, zostaniesz przy ESLint albo będziesz utrzymywać oba narzędzia równolegle.

Czy do lintowania TypeScriptu potrzebny jest pakiet typescript?

Nie do samego lintowania. Biome ma własny silnik wnioskowania i działa bez kompilatora TypeScriptu. Sprawdzanie typów to jednak osobna sprawa i tsc --noEmit nadal musi być w potoku, bo Biome go nie zastępuje.

Czy da się napisać własną regułę w JavaScripcie?

Nie. Jedyną drogą są wtyczki GritQL zapisane w plikach .grit i podłączone przez pole plugins. Mają dostęp do jednej funkcji dodanej przez Biome, register_diagnostic, obsługują JavaScript, CSS i JSON, nie widzą typów ani grafu modułów i nie przyjmują opcji.

Czy Biome formatuje YAML i Markdown?

Na dziś nie. Pełne wsparcie obejmuje JavaScript, TypeScript, JSX, JSON i JSONC, CSS oraz GraphQL. Vue, Svelte i Astro działają od wersji 2.3.0 jako funkcja eksperymentalna wymagająca jawnego włączenia. SCSS, YAML i Markdown są w trakcie prac.

Czy Biome jest płatny?

Nie. Cały projekt jest otwarty, na licencji MIT albo Apache 2.0 do wyboru, bez wariantu płatnego i bez ograniczeń w użyciu komercyjnym. Strona Enterprise nie zawiera cennika, tylko informację o współtwórcach przyjmujących płatne zlecenia oraz odnośniki do OpenCollective i GitHub Sponsors.

Jak uruchomić Biome na serwerze budującym?

Poleceniem biome ci, które niczego nie zapisuje i zwraca niezerowy kod wyjścia przy naruszeniach. Do integracji z widokiem zgłoszenia zmian przydaje się --reporter=github, a dostępne są też formaty gitlab, junit, checkstyle, sarif i json.

Dokumentację znajdziesz na stronie Biome, przewodnik migracji w dziale poradników, a kod źródłowy w repozytorium na GitHubie.