Strong project with excellent documentation and clear path to contribute, but browser build complexity and multi-package architecture create friction for newcomers trying to get a working dev environment.
last scored 2026-06-15
Readiness lenses
The same repo, two ways: how ready it is for an AI coding agent, and for a human newcomer. Switch lenses to see each one's score and checks.
How ready the repo is for an AI coding agent to read, build, and operate it.
26 of 35 checks passed across 6 categories.
Machine Orientation
6 checks passed2 problems found
- lowllms.txt present
An llms.txt is the emerging machine-orientation standard — a curated map for LLMs.
Fix: Add an llms.txt pointing at the key docs and entry points.
- lowArchitecture doc
An ARCHITECTURE doc hands an agent the module map instead of making it infer one.
Fix: Add an ARCHITECTURE.md describing the major components and how they fit.
- README present — An agent reconstructs what the repo is and how to work in it from the README first.
- Agent instructions file — AGENTS.md / CLAUDE.md is the direct, machine-read channel for entry points and conventions.
- Agent instructions stay lean — A bloated instructions file burns context and measurably hurts more than it helps.
- Repository description set — The one-line description is the fastest orientation signal an agent reads.
- Topics set — GitHub topics situate the repo's domain and stack for an agent at a glance.
- Contribution conventions are written down — A contributor guide is where an agent learns the branch, commit, and review conventions it must follow.
Reproducible Setup
3 checks passed3 problems found
- lowVersion pins are exact
A floating pin (a bare major, or a range) still drifts between installs.
Fix: Pin to an exact or minor version, not a floating range.
- lowEnv template present
A .env.example tells an agent which configuration keys it must supply to run.
Fix: Ship a .env.example listing every required key with placeholder values.
- lowDev container
A .devcontainer gives an agent a one-command, fully-declared environment.
Fix: Add a .devcontainer so the toolchain is declared, not assumed.
- Lockfile committed — Without a lockfile two clones can resolve different dependency trees — the build isn't reproducible.
- Runtime / toolchain pinned — An unpinned runtime makes an agent guess the version a clean environment needs.
- Container or dev-container — A Dockerfile / compose / devcontainer removes 'works on my machine' from setup.
Code Navigability
2 checks passed0 problems found
- Conventional source layout — A recognised src/ · lib/ · app/ layout lets an agent localise code without spelunking.
- TypeScript strict mode on — Strict typing gives an agent typed signatures to anchor an edit on, not guesses.
Verification Surface
6 checks passed1 problem found
- lowTypecheck command
A typecheck script lets an agent catch type errors before they ship.
Fix: Add a `typecheck` script (e.g. `tsc --noEmit`).
- Tests present — Runnable tests are the ground truth an agent checks its own edits against.
- Test command defined — A `test` script is the documented, discoverable way to run the suite.
- Lint command defined — A linter an agent can run catches a class of mistakes before they ship.
- CI configured — Readable CI is the feedback loop an agent reads to know what 'green' means here.
- Task runner present — A Makefile / Taskfile / justfile gives an agent a single index of the project's commands.
- Build command — A documented build command is the discoverable way for an agent to produce artifacts.
Agent Safety
6 checks passed2 problems found
- lowCODEOWNERS present
CODEOWNERS marks the 'don't touch without review' zones an agent should respect.
Fix: Add a CODEOWNERS file marking the sensitive paths.
- lowAutomated dependency updates
Dependabot / Renovate keeps dependencies patched without a human in the loop.
Fix: Enable Dependabot or Renovate.
- No committed .env — A tracked real .env hands secrets to anything — including an agent — that reads the repo.
- No exposed secrets — Secret-shaped literals in tracked files are a live credential leak.
- .gitignore covers env files — An ignore rule for .env is what keeps the next careless commit from leaking secrets.
- .gitignore present — A .gitignore is the first guard against an agent committing secrets or build junk.
- Security policy — A SECURITY.md is where an autonomous security agent reads this repo's rules before acting on it.
- License makes the code reusable — Without a license an agent cannot safely copy, redistribute, or vendor any of this code.
Context Economy
3 checks passed1 problem found
- lowNo oversized source file
A single file in the hundreds of KB blows past an agent's effective context window.
Fix: Split the largest files along their natural seams.
- Dependencies not vendored in — A committed node_modules / vendor tree drowns the real signal an agent needs.
- Build output not committed — Generated dist/ · build/ output is noise an agent has to read past.
- Generated / vendored files marked — A .gitattributes linguist marker tells tools (and agents) what to skip.
How ready the repo is for a human newcomer to understand, set up, and contribute.
82 / 10018 of 25 checks passed across 6 categories.
First Impression
92Clear, inviting, and purpose-driven—README leads with what Playwright does and offers multiple entry points for different user types.
The README immediately establishes the project's purpose (web automation and testing), who it's for (testers, agents, browser automation users), and how mature it is (high-quality framework with multiple interfaces—CLI, library, test runner, MCP server, VS Code extension). The table comparing install paths is smart: it segments use cases upfront. Code examples are present and runnable, showing the project's capabilities concretely.
Getting Running
71Clear install commands for users, but the developer setup is complex and demands a long chain of prerequisites with incomplete documentation on expected build time and dependencies.
The user-facing install (npm init playwright@latest) is straightforward. However, CONTRIBUTING.md for developers requires Node.js 20+, clone, npm ci, npm run watch, npx playwright install—and then warns that some files are generated, that the watch process may override changes, and that API types come from docs/src. There's no estimate of build time (likely 10+ minutes), no guidance on which test suite to run first, and the package.json shows complex tooling (babel, esbuild, rollup, typescript) without explaining the build architecture in plain terms. No lockfile format specified or pre-commit hooks mentioned.
Finding Your Way
75Multi-package workspace is well-structured and documented, but a newcomer must navigate across packages/playwright-core and packages/playwright without a visual architecture guide.
CONTRIBUTING.md correctly points to packages/playwright-core for browser APIs and packages/playwright for the test runner, and explains that docs/src is the source of API types. However, there's no diagram, no overview of how the packages relate, and no explanation of the tool pipeline (doclint, generate_channels.js, generate_types). The file tree shows 2958+ files but no README in the main source directories explaining module boundaries, file naming conventions, or where to look for specific functionality. A newcomer would struggle to find where to make a locator change vs. a test runner change.
Path to Contribute
88CONTRIBUTING.md is explicit, detailed, and addresses the full workflow from issue to PR, with clear test commands and lint guidance—though it enforces a gating policy that may discourage casual contributors.
The guide covers choosing an issue (must have a linked issue first), making a change (clone, install, build), running linters and tests (ctest, ftest, wtest for browsers; full test suite documented), adding tests, and writing docs. The linter setup (npm run lint) is comprehensive. However, the 'Unsolicited PRs will be closed' and 'Low-Quality AI Contributions will be closed without explanation' policies are strict and may chill participation. No beginner-labeled issues are mentioned in the snapshot, and the issue template (bug.yml, feature.yml, etc.) is present but not shown in detail.
Signs of Life
8891k stars, active CI/CD pipelines, recent push (2026-06-15), and multiple release workflows signal a healthy, well-staffed project.
The repository shows 91,011 stars, 168 open issues, and last push timestamp indicates recent activity. The .github/workflows directory lists 15+ workflows including publish_release.yml, tests_primary.yml, tests_secondary.yml, tests_docker.yml, roll_browser.yml, and roll_nodejs.yml—demonstrating active CI/CD, multiple test configurations, and regular browser/Node rollup cycles. The CHANGELOG is referenced as a live GitHub releases page. However, the snapshot doesn't show contributor count, response time to issues, or PR merge velocity, so confidence is moderate.
Open Door
85Clear Apache 2.0 license, Code of Conduct, Security policy, and multiple support channels (Discord, docs, SUPPORT.md, FILING_ISSUES.md) make it safe and welcoming to join.
LICENSE file is present (Apache 2.0), CODE_OF_CONDUCT.md is included, SECURITY.md is documented, and SUPPORT.md provides guidance. The README links to Discord (aka.ms/playwright/discord) and docs. FILING_ISSUES.md suggests a dedicated guide for issue etiquette. However, the strict contribution policy ('unsolicited PRs will be closed') and the warning about 'low-quality AI contributions being closed without explanation' add a layer of gatekeeping that, while understandable for a high-volume project, may feel unwelcoming to uncertain newcomers or first-time contributors.
First Impression
3 checks passed0 problems found
- README present — The README is the first screen — with none, a newcomer has nothing to land on.
- Repository description set — The one-line description sets expectations before a newcomer even opens the README.
- Topics set — Topics situate the project's domain at a glance and help a newcomer find it.
Getting Running
3 checks passed3 problems found
- lowEnv template present
A .env.example shows a newcomer exactly which settings they must fill in to run it.
Fix: Ship a .env.example listing every required key with placeholder values.
- lowOne-click dev container
A .devcontainer lets a newcomer start in a cloud IDE with zero local setup.
Fix: Add a .devcontainer for a one-click, batteries-included environment.
- lowVersions pinned exactly
A floating version still drifts — a newcomer can hit a break the maintainer never saw.
Fix: Pin prerequisites to an exact or minor version, not a floating range.
- Lockfile committed — Without a lockfile a newcomer's install resolves differently and hits errors the docs don't mention.
- Prerequisite versions pinned — Unpinned prerequisites are the classic 'works on my machine' first-run failure.
- One-command environment — A Dockerfile / compose / devcontainer turns a fiddly setup into one command.
Finding Your Way
1 check passed2 problems found
- mediumArchitecture / overview doc
An overview hands a newcomer the map instead of making them reconstruct it.
Fix: Add an ARCHITECTURE.md (or a 'Project layout' README section) naming the key directories.
- lowNo oversized source file
A single thousand-line file is a wall a newcomer bounces off.
Fix: Split the largest files along their natural seams.
- Conventional source layout — A familiar src/ · lib/ · app/ layout lets a newcomer guess where things live.
Path to Contribute
5 checks passed1 problem found
- lowPull-request template
A PR template tells a first-time contributor what a good change includes.
Fix: Add a PULL_REQUEST_TEMPLATE.md.
- CONTRIBUTING guide — A CONTRIBUTING guide is the difference between a guessed and a guided first PR.
- Issue templates — Issue templates show a newcomer how to file something useful — and that contributions are welcome.
- Test command defined — A documented test command lets a contributor check their change before opening a PR.
- Lint command — A linter lets a first-time contributor catch style issues before review.
- Task runner — A Makefile / Taskfile gives a contributor a single index of the project's commands.
Signs of Life
2 checks passed1 problem found
- lowAutomated dependency updates
Dependabot / Renovate activity is a visible heartbeat of ongoing maintenance.
Fix: Enable Dependabot or Renovate.
- Tests present — A test suite signals a project that's cared for, not abandoned.
- CI configured — Green CI on every change tells a newcomer the project is actively kept working.
Open Door
4 checks passed0 problems found
- License present — With no license the project isn't legally reusable — the door is shut however friendly the README.
- License is a standard one — A non-standard or custom license is a legal question mark a newcomer won't resolve.
- Code of conduct — A code of conduct states the social ground rules that make it safe to step in.
- Security policy — A SECURITY.md tells a newcomer how to report a problem responsibly.
Where the grip slips
- highGetting Running+12 pts if fixed
Developer setup lacks build-time estimate and architecture overview.
CONTRIBUTING.md tells a newcomer to npm ci, npm run watch, and npx playwright install, but doesn't explain what's being built, how long it takes (likely 15+ minutes), what the build output is, or whether they need to rebuild after every change. This causes frustration and false assumptions about whether the setup is broken. The instruction 'some files are generated by the build, so the watch process might override your changes if done in the wrong file' is vague without a guide to generated vs. source files.
Fix: Add a 'Development Environment' section to CONTRIBUTING.md with: (1) expected build time (e.g., 'First build takes ~15 min, watch mode rebuilds in ~2 min'); (2) a list of key generated files and their sources (e.g., 'types.ts comes from docs/src/*.md'); (3) a diagram or table showing packages/playwright-core, packages/playwright, and packages/playwright-test relationships; (4) a checklist of 'your setup is ready' tasks (e.g., 'npm run ctest runs without errors').
- highFinding Your Way+10 pts if fixed
No visual or textual architecture overview for the monorepo.
A newcomer opening the repo sees 2958+ files and a mention of 'Playwright is a multi-package repository' but no diagram showing how packages/playwright-core, packages/playwright, packages/playwright-test, packages/playwright-cli, and packages/playwright-mcp relate. There's no guidance on which package owns which feature, making it hard to locate where a bug fix or feature should go.
Fix: Create an ARCHITECTURE.md file at the repo root with: (1) a high-level diagram (text or ASCII art) showing package relationships; (2) a table listing each package's purpose, main entry point, and dependencies; (3) a flowchart of how a user request flows through the system (e.g., 'playwright test' → packages/playwright → packages/playwright-core → browser protocol); (4) a guide to key files in each package (e.g., 'To modify locator behavior, see packages/playwright-core/src/locator.ts').
- mediumPath To Contribute+8 pts if fixed
Contribution policy is gatekeeping and may discourage newcomers.
CONTRIBUTING.md states 'Unsolicited PRs submitted without a linked issue or prior approval will be closed' and 'PRs that do not meet quality standards or lack human oversight will be closed without explanation.' For a large open-source project, this is understandable, but it creates a barrier: newcomers with good ideas may file an issue, wait for triage, and give up if there's no timely response. No SLA or expected response time is mentioned.
Fix: Add to CONTRIBUTING.md: (1) expected issue-triage time (e.g., 'most issues triaged within 1 week'); (2) a link to the 'good first issue' or 'help wanted' label with a count; (3) explicit guidance on when unsolicited PRs might be welcome (e.g., 'documentation improvements, test additions'); (4) a section on getting unblocked (e.g., 'if your issue isn't triaged in 2 weeks, ping @maintainer-handle in Discord').
- mediumPath To Contribute+7 pts if fixed
No beginner-friendly issue labels or onboarding path visible.
The snapshot doesn't show evidence of 'good first issue', 'help wanted', 'beginner-friendly', or similar labels being used. A newcomer looking to contribute has no way to find tasks scaled to their skill level without reading through all 168 open issues.
Fix: Adopt GitHub's standard issue labels for onboarding: 'good first issue', 'help wanted', 'documentation', 'type: bug', 'type: feature'. Apply these consistently. Add a section to CONTRIBUTING.md: 'Start here: Look for issues labeled good first issue.' Link to the label filter (e.g., https://github.com/microsoft/playwright/issues?q=label%3A%22good+first+issue%22).
- mediumGetting Running+6 pts if fixed
Monorepo workspace structure not explained in dev setup.
CONTRIBUTING.md mentions 'Playwright is a multi-package repository that uses npm workspaces' but doesn't explain: how to install/build/test a single package, whether to run npm ci at the root or per-package, how workspaces affect local development, or which package owns which test suite.
Fix: Add a section 'Working with npm Workspaces' to CONTRIBUTING.md: (1) explain that npm ci at the root installs all packages; (2) show how to test a single package (e.g., 'npm test -w packages/playwright-core'); (3) clarify that build changes in watch mode apply to all packages; (4) link to npm workspaces documentation if helpful.
- mediumGetting Running+5 pts if fixed
Test suite documentation is incomplete and scattered.
CONTRIBUTING.md lists ctest, ftest, wtest, atest, etest, itest, stest, biditest, ttest, ct, and test-mcp but doesn't explain which one to run first, which are fast, which are slow, or which are required before submitting a PR. A newcomer might run all of them and wait 2+ hours, or run the wrong one and miss a regression.
Fix: Add a 'Testing' section to CONTRIBUTING.md with a table: | Suite | Config | Time | Browsers | When to run | | --- | --- | --- | --- | --- | | ctest | chromium | 15 min | Chromium | Always before PR | | ftest | firefox | 20 min | Firefox | Before merge | ... Add: 'For a quick sanity check, run: npm run ctest. For full validation before PR submission, run: npm run test.'
- lowPath To Contribute+4 pts if fixed
No pre-commit hooks or CI status check guidance for local development.
CONTRIBUTING.md says 'run npm run lint' but doesn't mention setting up pre-commit hooks, explain what lint checks (eslint, tsc, doc, check-deps, etc.), or show how to fix common lint failures. A newcomer runs lint for the first time and sees a wall of errors with no guidance on remediation.
Fix: Add a 'Linting and Code Quality' section: (1) explain what npm run lint does (eslint, typescript, docgen, dependency checks); (2) show common lint failures and fixes (e.g., 'unused variable → delete it'); (3) suggest setting up a pre-commit hook via husky (if used) or a custom script; (4) link to eslint.config.mjs for style rules.
Show your score
[](https://latch.fyi/microsoft/playwright)Share this analysis
https://latch.fyi/microsoft/playwrightFixed some issues? Re-analyze to measure your progress →
Copy the whole report
Grab the entire verdict in one go — a Markdown block for a README or an issue, plain text, or a prompt you can paste straight into an LLM.