Compiler Playground App

The Compiler Playground is an interactive application for demonstrating and testing React Compiler behavior. It lives under compiler/apps/playground and provides local development, browser-based end-to-end testing, and deployment through Vercel.

Its documented workflow builds React Compiler from source, installs the Playground dependencies, and starts a development server. The available excerpts show the compiler invocation and test harness, but they do not show the browser worker, editor event handler, or the complete per-keystroke execution path.

Sources: compiler/apps/playground/README.md:1-3, compiler/apps/playground/lib/compilation.ts:302-315

Core concepts

The Playground application

The Playground is the interactive app that demonstrates React Compiler and is developed with yarn dev or npm run dev.

Sources: compiler/apps/playground/README.md:1-3, compiler/apps/playground/README.md:17-23

Compiler synchronization

Compiler synchronization means rerunning yarn after local React Compiler changes so the Playground stays aligned with the compiler built from source.

Sources: compiler/apps/playground/README.md:24-27

Compilation invocation

Compilation invocation is the point where the Playground passes source, language, and parsed options to invokeCompiler.

Sources: compiler/apps/playground/lib/compilation.ts:302-315

Text snapshot testing

Text snapshot testing records the Playground’s expected textual output, with snapshots stored under the e2e test directory and intentionally independent of the host environment.

Sources: compiler/apps/playground/playwright.config.js:24-30

How the Playground is assembled

The setup path is deliberately repository-oriented: yarn builds React Compiler from source and installs the Playground dependencies, while Vercel repeats that installation behavior in the Playground directory and symlinks the compiler as a dependency. This is why the deployed app follows the compiler behavior from the commit being deployed.

The Next.js configuration enables the React compiler integration, view transitions, and strict mode. It also loads monaco-editor-webpack-plugin, indicating that the application’s build configuration includes Monaco editor integration, although the supplied excerpt does not show the editor component or its event flow.

The root layout imports global styles and renders the document shell. It also contains the 'use no memo' directive, but the excerpt does not show the child UI that presents source code, compiler options, or generated output.

The main visible compilation boundary is in compiler/apps/playground/lib/compilation.ts. The code copies baseOpts, adds logger behavior, calls invokeCompiler(source, language, opts), and catches failures. When a logger event has kind CompileError, its detail is converted and added to otherErrors.

The evidence does not establish that a Node build runs on every keystroke. It establishes a source-build and dependency-install step for development and deployment, plus an in-application call to invokeCompiler; the browser execution mechanism and editor change handler are outside the supplied excerpts.

The visible build-and-test boundary can be summarized as follows:

Sources: compiler/apps/playground/README.md:7-13, compiler/apps/playground/README.md:38-42, compiler/apps/playground/next.config.js:8-17, compiler/apps/playground/app/layout.tsx:8-17, compiler/apps/playground/lib/compilation.ts:302-315

What the end-to-end snapshots pin down

The documented test command is yarn test, after installing Playwright browser binaries with npx playwright install --with-deps.

Playwright discovers tests in __tests__/e2e, runs them in parallel, retries a failing test up to five times, and stores test artifacts under test-results/. Its snapshotPathTemplate places text snapshots in __tests__/e2e/__snapshots__ using the test-file path and snapshot argument.

The test configuration explicitly says that only text snapshots are used, so the snapshot contract is textual rather than a screenshot or host-environment-specific image.

The shown default-config.txt snapshot contains only the configuration text //compilationMode: "all". Therefore, this supplied snapshot pins down that exact default configuration text; it does not, by itself, prove the full compiled JavaScript output, DOM structure, compiler diagnostics, or every UI control.

Before tests begin, Playwright runs yarn dev through its webServer configuration, waits for baseURL, and reuses an existing server outside CI. This makes the e2e test run against the development server rather than requiring a separate manually started process in the normal configured flow.

Sources: compiler/apps/playground/README.md:29-35, compiler/apps/playground/playwright.config.js:18-30, compiler/apps/playground/playwright.config.js:27-30, compiler/apps/playground/tests/e2e/snapshots/page.spec.ts/default-config.txt:1-3, compiler/apps/playground/playwright.config.js:32-39

Where to extend a compilation-mode toggle

The supplied material does not identify the Playground’s page component, control component, or the test that renders the mode selector. Consequently, it is not possible to name the exact UI file for adding a new compilation-mode toggle from this pack alone.

The strongest visible integration point is compiler/apps/playground/lib/compilation.ts: parsed options are extended through baseOpts, and the resulting opts object is passed to invokeCompiler. A new mode would therefore need to reach this options path, but the excerpts do not show how UI state is converted into baseOpts or how the mode is serialized into the snapshot.

The existing snapshot gives one concrete test-facing value to inspect: compilationMode is shown as "all". If the UI gains another mode, the supplied evidence suggests checking the e2e snapshot expectations for the corresponding configuration text, while recognizing that the actual control wiring is not included here.

Sources: compiler/apps/playground/app/layout.tsx:8-17, compiler/apps/playground/tests/e2e/snapshots/page.spec.ts/default-config.txt:1-3, compiler/apps/playground/lib/compilation.ts:302-315

How it connects

The Playground’s source-build dependency connects it to the compiler workspace: local yarn builds React Compiler from source, and deployment repeats that relationship by symlinking the compiler as a dependency. For the compiler pipeline itself, see Compiler Overview & Pipeline.

The app is a Next.js surface with compiler integration enabled in next.config.js, while its compilation helper calls invokeCompiler and collects compiler errors through logger events. For the Babel-facing integration boundary, see Babel Plugin Integration.

The test harness connects the development server to Playwright through webServer, and its snapshots live under the e2e test tree. For broader repository test conventions, see Jest Test Infrastructure.

Sources: compiler/apps/playground/README.md:7-13, compiler/apps/playground/README.md:38-42, compiler/apps/playground/next.config.js:11-17, compiler/apps/playground/lib/compilation.ts:302-315, compiler/apps/playground/playwright.config.js:24-39

Key takeaways

• The Playground builds React Compiler from source during setup and deployment.
• invokeCompiler is the visible application-level compilation boundary.
• The shown e2e snapshot pins down text configuration, specifically compilationMode: "all".
• Playwright starts or reuses the development server before running e2e tests.
• The supplied excerpts do not reveal the exact UI file or browser mechanism for a new compilation-mode toggle.