01Transformuj składnię bez udawania, że uruchamiasz aplikację
Babel Transform Playground to zawężone narzędzie przeglądarkowe dla developerów, którzy chcą zrozumieć, jak Babel zmienia jeden fragment JavaScript, JSX, TypeScript albo TSX. Strona uruchamia Babel w jednorazowym workerze, pokazuje transformowany kod, próbkę zmienionych linii i opis pipeline, a wklejone źródło zostaje po stronie klienta. Produkt jest celowo węższy niż oficjalny Babel REPL: służy do szybkich artefaktów review, nie do wykonywania dowolnych pluginów ani udawania pełnej konfiguracji projektu.
02Co wspiera MVP
MVP wspiera kuratorowane tryby parsera dla JavaScript, JSX, TypeScript i TSX; targety syntax-only, modern browsers i legacy browser; source type module albo script; React classic lub automatic JSX runtime; compact output; komentarze; oraz małą allowlistę pluginów dla popularnych transformów składni, takich jak optional chaining, nullish coalescing, klasy, block scoping, template literals i arrow functions. Narzędzie używa realnego outputu @babel/standalone, ale nie przyjmuje kodu własnych pluginów od użytkownika.
03Dlaczego Babel transform to pytanie o pipeline
Babel często nazywany jest kompilatorem, ale w praktycznym code review pytanie jest zwykle bardziej konkretne: która część pipeline zmieniła ten plik? preset-env może obniżyć składnię pod target przeglądarek, preset-react obsługuje JSX, preset-typescript usuwa adnotacje typów, a pojedyncze pluginy mogą wymusić transform konkretnej rodziny składni. Pokazanie tych decyzji obok outputu jest bardziej użyteczne niż czarne pudełko z textarea. Dlatego playground raportuje option chips, opis pipeline i małą próbkę diffu poza samym transformowanym kodem.
Granica TypeScript jest szczególnie ważna. Babel potrafi parsować i usuwać adnotacje TypeScript, ale nie robi typecheckingu. To oznacza, że snippet może przejść transform poprawnie, nawet jeśli system typów by go odrzucił. Strona mówi to wprost, bo to częste źródło nieporozumień przy migracjach z tsc, Vite, SWC, esbuild albo frameworkowych buildów. Traktuj output jako artefakt składniowy, nie jako dowód bezpieczeństwa typów.
Granica bezpieczeństwa jest równie jawna. Strona nigdy nie wykonuje transformowanego outputu. Źródło zawierające alert, fetch, pętle albo importy po transformie nadal jest tylko tekstem. MVP blokuje wzorce Babel registerPlugin i registerPreset, bo własne pluginy Babel wykonują JavaScript i zamieniłyby publiczny transformer w sandbox pluginów. To jest poza zakresem produktu. Publiczna trasa unika też CDN, zdalnego rozwiązywania pluginów i backendowych transformów. Babel jest lazy-loaded w workerze, żeby cięższy kod kompilatora nie był częścią początkowego payloadu trasy.
04Workflow review dla decyzji Babel
Zacznij od presetu bliskiego rozmowie: TypeScript do legacy JavaScript dla optional chaining i nullish coalescing, TSX z React automatic runtime dla komponentów, klasy dla starszego outputu albo syntax-only JSX, gdy chcesz odizolować zachowanie JSX. Zmieniaj jedną opcję naraz i skopiuj wygenerowany snippet Babel.transform do komentarza w pull requeście, jeśli zespół potrzebuje odtwarzalności. Panel diff jest celowo mały; pomaga w decyzji, ale nie zastępuje pełnego patch view.
Przenieś temat do realnego builda repozytorium, gdy pytanie dotyczy importów, zależności npm, targetów z browserslist, frameworkowych transformów, plików konfiguracyjnych Babel, aliasów monorepo, polyfilli, strategii helperów albo minifiera. Playground może pokazać, jak zmienia się lokalny snippet, ale produkcyjny build nadal musi udowodnić cały graf. Ta granica czyni narzędzie użytecznym dla użytkowników z wyszukiwarki i senior reviewerów: daje szybką odpowiedź bez udawania CI. Dla publicznego indeksowania ta jasność ma znaczenie. Otaczający artykuł wyjaśnia, co Babel zmienia, czego nie może udowodnić i dlaczego tryb TypeScript nie jest typecheckerem. Użytkownik z wyszukiwarki może od razu użyć interaktywnej części, ale ta sama strona nadal ma wystarczająco dużo oryginalnej treści wydawcy, żeby działać jako samodzielna referencja. Właśnie dlatego narzędzie trzyma edytor, diff, pipeline, ograniczenia i FAQ razem, zamiast chować wyjaśnienie w osobnej dokumentacji. W praktyce pomaga to też zespołom nietechnicznym: product owner widzi granice ryzyka, developer widzi realny output, a reviewer dostaje artefakt, który można wkleić do decyzji bez tłumaczenia całego stacku buildowego od zera. Dodatkowo strona porządkuje różnice między decyzją edukacyjną i produkcyjną. Jeśli output pokazuje ciekawą zmianę składni, to jest dobry początek rozmowy, ale nie zastępuje testów jednostkowych, konfiguracji Babel w repozytorium, ustawień browserslist, polyfilli ani pomiaru bundle size w prawdziwej aplikacji. Takie rozdzielenie obietnic chroni przed nadinterpretacją wyników i podnosi jakość decyzji technicznych.