11.2 — Setup: what npm init playwright scaffolds
9.8 left you with a real Node workspace and a promise: “this is what Playwright installs into.” Today the promise lands: one command interviews you, scaffolds a complete working suite, downloads three real browsers — and two minutes later you run passing tests.
The goal today isn’t just to run it — it’s to know exactly what every scaffolded file IS, so nothing in your project is mystery furniture.
$ npm init playwright@latest ✔ TypeScript or JavaScript? · TypeScript ✔ Where to put your tests? · tests ✔ Add a GitHub Actions workflow? · true ✔ Install Playwright browsers? · true first-suite/ ├─ playwright.config.ts ← 11.3 decodes it ├─ package.json ← you read these cold (8.6) ├─ tests/example.spec.ts └─ .github/workflows/playwright.yml ← 11.16 $ npx playwright test Running 2 tests using 2 workers 2 passed (4.2s) $ npx playwright test --headed $ npx playwright show-report
Setting: your 9.8 workspace — Node LTS installed, a project folder, a terminal standing in it. That’s the complete list of prerequisites. Everything Playwright needs, you built two phases ago, by hand, knowing every piece.
The deeper story, with the real names for things — this part is what turns “I saw it” into “I can explain it.”
Where the browsers actually live: a per-user cache (on Linux ~/.cache/ms-playwright, equivalents elsewhere) — shared across all your projects, keyed by version. npx playwright install re-downloads on demand; CI machines run it every time (11.16’s fresh-box rule), usually behind a cache step.
The example spec is worth five minutes of honest reading: it navigates to playwright.dev and asserts on the page — a real network round trip (6.7). Some teams delete it on day one; better: keep it until your own first spec passes, as a known-good canary for “is my setup broken or is my test wrong?”
If TypeScript feels like overhead in week one: the scaffold works identically with the JavaScript answer, and everything in this phase applies unchanged. But 8.5’s argument stands — page. autocompleting every action is worth the one-letter extension, and every real codebase you join will have chosen TS already.
Job note: run the init in an EMPTY folder, not inside an existing app, while learning — one suite, one repo keeps the mental model clean. At work you’ll usually find the suite inside the app repo (an e2e/ folder) — same files, same reading order: config first, then one spec.
⌨️ the scaffold inspector
A teammate says “I ran the init but something’s off.” Write the inspector: verify a scaffold has every required file, and name exactly what’s missing when it doesn’t.
requirements:
- Create
required: the four scaffold files —"playwright.config.ts","package.json","tests/example.spec.ts",".github/workflows/playwright.yml". - Write
inspect(files): compute the missing ones (required entries the files list doesn’t include — 4.9 + membership). If none are missing, printscaffold complete; otherwise printmissing: NAMEfor each. - Run it twice: once on a complete scaffold, once on one where
playwright.config.tswas deleted.
when you press RUN, the console must show exactly:
✏️ Quick check 1
Why is the Playwright install download so large — what is it actually downloading?
✏️ Quick check 2
How does the runner know tests/example.spec.ts contains tests?
✏️ Quick check 3
Which flag opens a visible browser window so you can watch the test drive?
🗣️ Now teach it back
Walk a friend through npm init playwright@latest: the four questions and how you’d answer them (with reasons), why the download is big, what each scaffolded file is, and the two commands you run right after.
Write it as if your friend is sitting next to you. Saved to your journal — future-you will use these notes to teach others.