Czym jest Prettier?

Precyzyjna definicja narzędzi w słowniku tworzenia stron www powinna nie tylko wyjaśniać, czym dane rozwiązanie jest, ale także jak wpływa na codzienną pracę przy kodzie, jak je wdrożyć i jak uniknąć pułapek. Prettier to jeden z kluczowych elementów warsztatu front-endowca i full-stacka, bo standaryzuje formatowanie kodu, zdejmuje z zespołów ciężar sporów o przecinki, wcięcia czy długości linii i przenosi rozmowę na poziom architektury, testów i jakości funkcjonalnej. Ten wpis porządkuje pojęcia, procedury i dobre praktyki tak, abyś mógł świadomie i konsekwentnie włączyć Prettiera do swoich projektów — od prostych stron statycznych po rozbudowane monorepo, aplikacje SPA, SSR i serwery Node.

Czym jest Prettier i jak go rozumieć w ujęciu słownikowym

Prettier to automatyczny formater kodu: program, który bierze pliki źródłowe i przepisuje je zgodnie z ustalonym, konsekwentnym zestawem reguł estetycznych. Nie jest linterem w klasycznym sensie (nie analizuje błędów logicznych czy antywzorów), tylko rozwiązaniem dbającym o spójny wygląd tekstu programu. Działa na wielu językach i formatach, które spotykamy w tworzeniu stron i aplikacji webowych: JavaScript, TypeScript, JSX/TSX, CSS/SCSS/Less, HTML, Markdown, JSON, YAML, GraphQL, a poprzez ekosystem parserów również na plikach konfiguracyjnych i szablonach popularnych frameworków.

W definicji słownikowej warto podkreślić cztery cechy:

Automatyzacja: Prettier nie proponuje zmian — on je wykonuje. W praktyce ogranicza to do minimum decyzje estetyczne, bo podejmuje je za autora, zgodnie z własną, stabilną logiką.
Konsekwencja: ten sam kod wejściowy zawsze prowadzi do tego samego efektu — bez wyjątków i losowości.
Minimalna przestrzeń ustawień: celowo ograniczona liczba przełączników eliminuje rozjazdy między projektami i pomaga utrzymać jednolity wygląd kodu w skali organizacji.
Nacisk na ergonomię: współpraca z edytorami, integracja z systemami kontroli wersji i skryptami projektowymi sprawiają, że formatowanie może dziać się w tle i nie wymaga pamiętania o dodatkowych krokach.

W kontekście procesu wytwórczego Prettier funkcjonuje jako narzędzie uruchamiane lokalnie w edytorze lub w komendach projektu, ale także w pipeline’ach CI, gdzie pełni rolę bramki jakościowej. Może być zintegrowany z hookami pre-commit, dzięki czemu zmiany w repozytorium zawsze spełniają ustalony standard.

Po co używać Prettiera: uporządkowana motywacja i twarde korzyści

Decyzja o wdrożeniu automatycznego formatowania bywa dyskutowana na poziomie zespołów i organizacji. Dobrze zdefiniowana motywacja ułatwia uzasadnienie i spaja strategię pracy z kodem. Poniżej najważniejsze, mierzalne powody:

Redukcja tarć komunikacyjnych i przestojów: spory o to, czy średnik ma być wstawiany, gdzie łamać linie lub ile spacji powinno być przed nawiasem, są z natury nieproduktywne. Prettier zapewnia jednoznaczny wynik i zamyka temat.
Lepszy przepływ pracy: w trybie Format on Save oraz we współpracy z hookami commitowymi programista nie musi pamiętać o dodatkowych zadaniach — formatowanie dzieje się automatycznie.
Spójność w monorepo i dużych zespołach: nawet przy dziesiątkach repozytoriów i setkach autorów otrzymujemy jednolity, przewidywalny wygląd kodu.
Lepsze code review: recenzenci skupiają się na logice i architekturze, a nie na stylu. Zmniejsza to obciążenie poznawcze i skraca czas przeglądów.
Stabilność narzędzi: Prettier ma dojrzały ekosystem i szerokie wsparcie w edytorach. Łatwo go osadzić w istniejącym łańcuchu narzędzi.
Języki dokumentacyjne i dane: uporządkowany Markdown, YAML i JSON poprawiają czytelność dokumentacji, definicji CI/CD i plików konfiguracyjnych.

W ujęciu pewnych słów kluczowych: Prettier porządkuje stylistyka, poprawia wydajność pracy zespołów (bo skraca dyskusje i automatyzuje monotonne czynności) i zmniejsza liczbę nieistotnych konfliktów merge. Nawet jeśli wydaje się, że decyzje o spójnikach czy średnikach są błahe, w sumie potrafią zmarnować godziny w sprintach, szczególnie przy ciągłej integracji i częstych commitach.

Warto też odnotować aspekt edukacyjny: młodsi programiści szybciej nasiąkają zdrowymi nawykami, bo widzą, jak kod jest natychmiast układany w spójny, przewidywalny kształt. To obniża próg wejścia i ułatwia czytanie cudzych zmian.

Jak działa Prettier pod maską i co dokładnie formatuje

Prettier nie przestawia losowo spacji i nowych linii. Jego serce to parsery, które zamieniają tekst źródłowy na strukturę pośrednią — drzewo składniowe. Kluczowa jest tu właściwość: drukowanie kodu ma charakter deterministyczny. Dla danych wejściowych A wynik B jest zawsze taki sam, niezależnie od człowieka czy maszyny, na której uruchamiamy narzędzie.

Mechanizm przetwarzania można w uproszczeniu opisać tak:

Parsowanie: Prettier buduje reprezentację AST (Abstract Syntax Tree) dla danego języka przy pomocy odpowiednich parserów (np. dla TypeScriptu używa parsera z ekosystemu TS, dla JS może korzystać z parserów kompatybilnych z nowymi propozycjami składni).
Reprezentacja do druku: drzewo jest przepisywane do abstrakcyjnego modelu linii i bloków, który uwzględnia długość linii, łamanie, komentarze i miejsca niedrukowalne.
Generowanie tekstu: algorytm generuje końcowy kod z zachowaniem zasad szerokości linii, nawiasów, odstępów i przenoszenia wierszy. Efekt jest idempotentny: ponowne uruchomienie na już sformatowanym pliku nie powinno nic zmienić.

Obsługiwane typy plików są szerokie: od JavaScript/TypeScript, przez Vue i Svelte (gdzie formatowanie dotyka zarówno skryptów, jak i szablonów), po style (CSS, SCSS, Less), a także dokumenty i dane (Markdown, MDX, JSON, YAML). W HTML Prettier porządkuje wcięcia, atrybuty i łamanie wierszy, starając się zachować semantyczny sens. W Markdown potrafi reflowować tekst według szerokości, zachowując integralność linków i list. W YAML i JSON dba o wcięcia, odstępy po dwukropkach i przecinkach oraz końcowe nowe linie.

Wszystko to działa w duchu praktyk DevEx: narzędzie respektuje wyłączenia kontekstowe. Można użyć komentarzy w stylu uzupełnianym przez parser (np. uzupełnionych o frazy w rodzaju prettier-ignore) do chwilowego pominięcia formatowania skrawka kodu, np. przy delikatnym układzie tablic lub kolumn, gdy estetyka manualna jest ważniejsza niż algorytmiczna. Takie wyłączenia powinny być jednak wyjątkiem, a nie regułą — im mniej wysp nieformatowanego kodu, tym mniej zaskoczeń dla innych uczestników projektu.

Współcześnie Prettier może być też rozszerzany przez społeczność. Ekosystem parserów i dodatków pozwala go dostosować do niszowych języków domenowych. Mówiąc o rozszerzalności, warto wspomnieć o plug-iny, które umożliwiają obsługę dodatkowych formatów lub niestandardowych konwencji w ramach istniejących języków. Trzeba jednak pamiętać, że Prettier celowo ogranicza pole manewru w kwestii gustu — wtyczki dodają wsparcie, ale nie zamieniają Prettiera w całkowicie dowolny, konfigurowalny beautifier.

Instalacja, uruchamianie i trwała konfiguracja

Prettiera instaluje się lokalnie w projekcie, rzadziej globalnie. Lokalne zainstalowanie zapewnia powtarzalność między członkami zespołu i środowiskami CI. Standardowa procedura obejmuje:

Dodanie zależności deweloperskiej: npm install –save-dev prettier lub pnpm add -D prettier czy yarn add -D prettier.
Utworzenie pliku ustawień: .prettierrc, .prettierrc.json, .prettierrc.yaml, .prettierrc.js czy wpis w package.json pod kluczem prettier. Wybór formatu zależy od preferencji i potrzeby komentarzy lub warunków.
Ustalenie ignorowanych ścieżek: .prettierignore, analogicznie do .gitignore. Warto tam umieścić buildy, artefakty, katalogi vendor oraz pliki generowane automatycznie.
Dodanie skryptów: w package.json przydatne są komendy w rodzaju prettier –check . lub prettier –write . z odpowiednimi filtrami (np. src/).

Zakres ustawień Prettiera jest wąski, ale wystarczający do zapanowania nad najczęstszymi niuansami. Przykładowe opcje to szerokość wiersza (często 80–100–120), wielkość wcięcia i sposób wcięć (spacje vs tabulatory), średniki (dodawać czy nie), cudzysłowy pojedyncze vs podwójne, przecinki końcowe w strukturach wielowierszowych, odstępy wokół nawiasów. Prettier czyta też część parametrów z EditorConfig, synchronizując np. ustawienia końców linii lub znaków białych na końcu plików.

Przy wdrożeniu w istniejącym repozytorium warto przejść przez kontrolowaną migrację:

Wprowadź konfigurację w najmniejszym możliwym zakresie i uzgodnij parametry z zespołem (zwłaszcza szerokość linii, cudzysłowy i średniki — to najczęstsze punkty wrażliwe w historii repozytoriów).
Uruchom konwersję na wydzielonej gałęzi i sprawdź, czy nie dochodzi do kolizji z innymi narzędziami, zwłaszcza linterami.
Skonfiguruj edytory (patrz niżej) i Format on Save, aby zmiany były spójne już przy pierwszych kolejnych commitach.
Włącz Prettiera do pipeline’u CI w trybie sprawdzania (check) — dzięki temu build przerwie się, jeśli ktoś pominął formatowanie lokalnie.

Dobra praktyka to też trzymanie Prettiera w tej samej wersji na wszystkich gałęziach długowiecznych. Aktualizacje mogą delikatnie zmieniać drukowanie krawędziowych przypadków; warto planować je świadomie i w porozumieniu z interesariuszami.

Integracje i automatyzacja: edytory, hooki i CI/CD

Prettier największą wartość przynosi wtedy, gdy działa zawsze i wszędzie, a programista nie musi o nim pamiętać. Stąd nacisk na bezproblemowe integracje z narzędziami dnia codziennego:

Edytory: Visual Studio Code ma rozszerzenie Prettier – Code formatter. Po włączeniu ustawienia Format on Save i wskazaniu Prettiera jako domyślnego formatera dla wspieranych języków, każde zapisanie pliku przeprowadza korektę. WebStorm/IntelliJ oferuje wsparcie natywne i przez wtyczkę; podobnie Vim i Neovim (np. przez null-ls lub dedykowane pluginy) oraz Emacs.
Hooki pre-commit: narzędzia takie jak Husky i lint-staged pozwalają uruchomić Prettiera tylko na zmienionych plikach. To drastycznie skraca czas, bo nie trzeba przechodzić po całym repo przy każdym commicie.
Integracja z systemami kontroli wersji: spójny format zmniejsza konflikty merge, a jeśli do nich dojdzie, Prettier po scaleniu przywraca ład w kodzie.
CI/CD: w pipeline’ach polecenie weryfikujące (prettier –check) stanowi bramkę jakościową. Jeśli ktoś zapomni o formacie lokalnie lub użył innego narzędzia, build uczciwie to zasygnalizuje.

W edytorach bazujących na językowych serwerach (LSP) Prettier bywa jednym z kilku formatów. Dobrze jest wskazać jednoznacznie, że ma on pierwszeństwo dla obsługiwanych typów plików. Równie istotne jest wyłączenie alternatywnych formaterów w konfliktujących zakresach, aby uniknąć zjawiska przepisywania kodu raz w jedną, raz w drugą stronę.

W monorepo Prettier może być skonfigurowany globalnie w katalogu głównym, a szczególne pakiety mogą stosować overrides — reguły dla dopasowanych maskami plików. Dzięki temu np. dokumentacja Markdown i kod TS mogą mieć różne szerokości wiersza, jeśli to uzasadnione charakterem zawartości.

Prettier a ESLint, styleguide i rola zasad projektowych

Prettier i linter to różne narzędzia, mimo że oba dotyczą jakości kodu. Lintery (np. ESLint) wykrywają błędy logiczne, niekonsekwencje i antywzorce, pomagają też wprowadzać zasady projektowe oraz reguły dla wzorców architektonicznych. Prettier dba o wygląd kodu. Ten podział ról jest kluczowy, aby uniknąć konfliktów i duplikatów.

W praktyce łączenie działań wygląda tak:

Wyłącz stylistyczne reguły lintera, które dublują operacje Prettiera (np. odstępy, cudzysłowy, łamanie linii). Służą do tego zestawy konfiguracyjne w stylu eslint-config-prettier, które odpinają kolizyjne zasady.
Jeżeli zespół chce raportować różnice formatowania w trakcie lintowania, można uruchomić Prettiera jako regułę przez odpowiednie wtyczki, ale częściej i czyściej jest trzymać te światy oddzielnie: Prettier wykonuje zapis, linter weryfikuje semantykę i dobre praktyki.
Ustal kolejność działań w pipeline’ach: zwykle najpierw uruchamia się formatowanie, potem lint i testy. Taki przepływ minimalizuje szum w raportach i diffach.

Styleguide pozostaje potrzebny. Prettier nie rozstrzyga o nazewnictwie, architekturze folderów, gęstości testów, czy konwencjach importów (poza łamaniem linii). Dlatego dojrzały projekt łączy Prettiera z linterami i dokumentem polityki kodu, który opisuje m.in. preferowane wzorce projektowe, organizację modułów, konwencje domenowe i granice między warstwami aplikacji.

Pamiętaj też o edukacji: jasne README w repo, z sekcją Jak uruchomić formatowanie i Jak działa nasz lint, oszczędza mnóstwo czasu nowym członkom zespołu. Warto dopisać wskazówki dla najpopularniejszych edytorów i krótką sekcję rozwiązywania problemów (np. co zrobić, gdy Format on Save nie działa).

Najlepsze praktyki, pułapki i specyfika poszczególnych formatów

Wdrożenie Prettiera to nie tylko instalacja pakietu. Długofalową satysfakcję zapewnia kilka nawyków i decyzji architektonicznych:

Stabilna baza: trzymaj konfigurację w repo w formacie czytelnym dla zespołu. Jeśli potrzebujesz komentarzy i warunków, użyj formatu JS lub YAML. Jeśli chcesz prostoty — JSON lub wpis w package.json.
Jedno źródło prawdy: nie utrzymuj wielu sprzecznych konfiguracji. W monorepo trzymaj centralny plik i używaj sekcji overrides dla wyjątków, zamiast tworzyć rozproszone kopie.
Współpraca z EditorConfig: pozwól, aby EditorConfig i Prettier współgrały (np. definicja końców linii), a nie konfliktowały. Zasady dotyczące wcięć i szerokości linii powinny być spójne po obu stronach.
Umiarkowanie w wyjątkach: komentarze ignorujące formatowanie stosuj oszczędnie. Jeśli sekcje wyjątków rosną, przyjrzyj się, czy nie da się lepiej wyrazić intencji kodu.
Wersjonowanie: aktualizacje Prettiera przeprowadzaj świadomie. Przetestuj na gałęzi, uruchom –check na całym drzewie, obejrzyj najbardziej ruchliwe katalogi. Jeśli zmiany w druku są rozległe, rozważ odrębny commit refaktoryzacyjny z samym formatem.
Skalowanie na CI: w dużych repozytoriach ograniczaj powierzchnię działania do zmienionych plików, a pełne skany uruchamiaj okresowo lub w dedykowanych zadaniach nocnych.

Specyfika formatów i języków:

Markdown: domyślne zawijanie akapitów bywa zaskoczeniem przy recenzjach, bo zmienia wiele linii. Jeżeli zespół preferuje ręczne łamanie, ustaw parametry zawijania tak, aby minimalizować różnice lub rozważ wyłączenie reflow dla długich akapitów.
HTML i szablony: w niektórych projektach istotny jest układ atrybutów. Prettier dokonuje własnych wyborów łamania. Jeśli to koliduje z potrzebami, sprawdź, czy parser i wersja wspierają oczekiwane zachowanie lub rozważ wyjątki per linia.
YAML: Prettier porządkuje wcięcia i odstępy, ale semantyka YAML bywa subtelna (np. wielowierszowe wartości). Warto uruchamiać walidatory YAML obok Prettiera, aby złapać przypadkowe regresje.
JSON i pliki lock: nie formatuj plików blokujących zależności narzędziem innym niż menedżer pakietów. Dla zwykłego JSON-u Prettier jest bezpieczny, ale pliki lock mają własną, ściśle kontrolowaną strukturę.
CSS/SCSS: porządkowanie deklaracji i łamanie długich reguł ułatwiają review, ale Prettier nie sortuje właściwości według semantyki. Jeśli taka polityka jest wymagana, wspieraj się dodatkowymi narzędziami (np. stylelintem).

Aspekty ergonomii zespołowej obejmują też dokumentację. Dodaj do CONTRIBUTING.md krótki akapit o uruchamianiu formatu lokalnie i o tym, że pipeline CI może odrzucić commit niezgodny z polityką formatowania. Ustal też, czy formatowanie jest obowiązkowe w każdej gałęzi funkcjonalnej czy dopuszczacie okresowe ujednolicanie stylistyki przy okazji większych refaktoryzacji.

FAQ

Co odróżnia Prettiera od klasycznego beautifiera? Prettier opiera się na analizie składni i druku kontrolowanym przez reguły szerokości linii, a nie na naiwnych podmianach spacji. Jego celem jest przewidywalny rezultat i idempotencja, co eliminuje dryf stylistyczny między uruchomieniami.
Czy Prettier zastępuje linter? Nie. Linter dba o jakość semantyczną i zgodność z praktykami kodowania, a Prettier o wygląd tekstu. Razem tworzą komplementarny duet.
Czy mogę wymusić nietypowe preferencje estetyczne? Zakres opcji jest ograniczony celowo, aby uciąć spory o gust. Możesz ustawić m.in. szerokość linii, wcięcia, średniki, cudzysłowy, przecinki końcowe. Bardziej szczegółowe preferencje zwykle nie są wspierane.
Jak uruchomić Prettiera tylko na zmienionych plikach? Skorzystaj z lint-staged i hooków pre-commit (np. przez Husky). Dzięki temu formatowany jest wyłącznie zestaw plików w staging area, co przyspiesza pracę.
Czy Prettier może zepsuć kod? Prettier działa na poziomie formatu, nie powinien zmieniać semantyki. W przypadku bardzo nowych konstrukcji składniowych ważny jest dobór parsera i wersji. Dlatego aktualizacje przeprowadzaj świadomie, z pełnym testem repozytorium.
Jak ignorować fragment pliku? Użyj komentarza ignorującego poprzedzającego dany węzeł kodu, aby pominąć pojedynczą instrukcję, wyrażenie lub blok. Stosuj to oszczędnie i dokumentuj powód, aby inni rozumieli kontekst.
Czy Prettier wspiera EditorConfig? Tak, Prettier potrafi respektować część ustawień EditorConfig, zwłaszcza tych dotyczących końców linii i znaków białych. Upewnij się, że wartości nie stoją ze sobą w sprzeczności.
Jak skonfigurować Prettiera w monorepo? Umieść plik konfiguracyjny w katalogu głównym i użyj sekcji overrides dla wyjątków per pakiet. Skrypty formatowania mogą działać z poziomu root z odpowiednimi maskami ścieżek.
Czy da się wymusić formatowanie w CI bez zmiany plików? Tak. Użyj polecenia w trybie weryfikacji, które zwraca niezerowy kod wyjścia, jeśli któryś plik wymaga przepisania. Dzięki temu pipeline został przerwany, ale repo pozostaje nienaruszone.
Jak radzić sobie z długimi łańcuchami i wyrażeniami? Prettier automatycznie łamie linie zgodnie z wybraną szerokością. Jeżeli to generuje nieczytelny zapis, rozważ pomocnicze zmienne lub przekształcenie konstrukcji na bardziej deklaratywną — to zwykle poprawia czytelność.
Czy można formatować tylko wybrane typy plików? Tak. W skryptach wskaż odpowiednie rozszerzenia lub foldery. Możesz też używać .prettierignore, aby globalnie wykluczyć katalogi lub konkretne pliki.
Jak łączyć Prettiera z narzędziami do sortowania importów? Prettier nie sortuje semantycznie importów. Jeśli taka polityka jest wymagana, zastosuj dedykowane narzędzia i uruchamiaj je przed Prettierem lub w skoordynowanej kolejności, tak aby nie wchodziły sobie w drogę.
Czy Prettier wpływa na rozmiar diffów? Tak, i to pozytywnie. Po wstępnym ujednoliceniu stylu kolejne zmiany dotyczą zwykle tylko faktycznie modyfikowanych fragmentów, a nie całych bloków różniących się wyłącznie odstępami i łamaniem linii.
Co z plikami generowanymi automatycznie? Zwykle dodaj je do .prettierignore. Formatowanie generatów bywa zbędne, a czasem utrudnia diagnozę różnic między kolejnymi generacjami.