A mature, well-run compiler project with excellent structure and docs, but getting a dev environment running requires non-trivial setup knowledge.
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.
24 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
- mediumContainer or dev-container
A Dockerfile / compose / devcontainer removes 'works on my machine' from setup.
Fix: Add a Dockerfile, a compose file, or a .devcontainer so the environment is declared, not assumed.
- 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.
- Version pins are exact — A floating pin (a bare major, or a range) still drifts between installs.
Code Navigability
1 check passed1 problem found
- lowTypeScript strict mode on
Strict typing gives an agent typed signatures to anchor an edit on, not guesses.
Fix: Turn on `strict` in tsconfig.json.
- Conventional source layout — A recognised src/ · lib/ · app/ layout lets an agent localise code without spelunking.
Verification Surface
5 checks passed2 problems found
- lowTask runner present
A Makefile / Taskfile / justfile gives an agent a single index of the project's commands.
Fix: Add a Makefile / Taskfile / justfile collecting the common commands.
- 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.
- Build command — A documented build command is the discoverable way for an agent to produce artifacts.
Agent Safety
5 checks passed3 problems found
- mediumSecurity policy
A SECURITY.md is where an autonomous security agent reads this repo's rules before acting on it.
Fix: Add a SECURITY.md stating the disclosure channel and the repo's security rules.
- 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.
- License makes the code reusable — Without a license an agent cannot safely copy, redistribute, or vendor any of this code.
Context Economy
4 checks passed0 problems found
- 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.
- No oversized source file — A single file in the hundreds of KB blows past an agent's effective context window.
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
92Crystal-clear what the project is: a compiler for building efficient web applications.
The README immediately states the core value proposition ('a compiler that takes your declarative components and converts them into efficient JavaScript that surgically updates the DOM'), links to a full website and Discord community, and includes a roadmap reference. The banner and concise tagline 'web development for the rest of us' set a professional, welcoming tone.
Getting Running
68Package manager and basic build tools are clear, but dev setup instructions are nowhere to be found.
The root package.json specifies `pnpm@10.4.0` as the package manager and shows build/test/lint scripts, making it possible to infer basic commands. However, there are no explicit instructions on Node version, local dev setup, cloning the monorepo, or how to run tests for someone unfamiliar with pnpm workspaces. A newcomer would have to reverse-engineer the structure or check the CONTRIBUTING guide (which is truncated and doesn't include setup steps in the visible portion).
Finding Your Way
85Monorepo structure is logical and well-organized, though no high-level architecture doc is visible.
The file tree shows a clean split (packages/svelte, documentation/, benchmarking/, .github/workflows/) with consistent naming and clear boundaries. The partial CONTRIBUTING.md mentions process (RFCs, roadmap, maintainer meetings) and the presence of issue labels ('good first issue') signal good structure. However, there is no ARCHITECTURE.md or overview of how the compiler phases work, leaving a newcomer to puzzle through phase-1-parse, phase-2-analyze, etc.
Path to Contribute
79Explicit guidance on contribution types, issue triage, and RFC process, but dev setup steps are missing from the visible excerpt.
The CONTRIBUTING.md is detailed and welcoming, listing multiple ways to contribute (using Svelte, triaging, fixing issues, reading tutorials), points to 'good first issue' labels, and explains the RFC and roadmap process. However, the visible portion is truncated after the 'Prioritization' section, and no explicit 'Developer Setup' or 'How to Run Tests' section is shown. The root README does point to CONTRIBUTING.md and the packages/svelte README, suggesting setup info may be there.
Signs of Life
88Active project with recent commits, clear release process, and structured governance.
Last pushed 2026-06-15 (within snapshot date), 87k stars, organized GitHub workflows (autofix, ci, release), changesets-based version management, and monthly maintainer meetings all signal strong maintenance. Open issues (1028) and the structured triage process indicate responsive engagement rather than abandonment.
Open Door
90MIT license, code of conduct, and active Discord community all in place; legal and social barriers are low.
LICENSE.md is present, MIT badge in README, CODE_OF_CONDUCT.md exists, and Discord link (svelte.dev/chat) is prominently featured for questions. FUNDING.json and Open Collective reference show sustainability intent. No heavyweight legal gate or contributor license agreement is visible.
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
- mediumOne-command environment
A Dockerfile / compose / devcontainer turns a fiddly setup into one command.
Fix: Add a Dockerfile, a compose file, or a .devcontainer for a one-command setup.
- 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.
- 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.
- Versions pinned exactly — A floating version still drifts — a newcomer can hit a break the maintainer never saw.
Finding Your Way
2 checks passed1 problem 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.
- Conventional source layout — A familiar src/ · lib/ · app/ layout lets a newcomer guess where things live.
- No oversized source file — A single thousand-line file is a wall a newcomer bounces off.
Path to Contribute
5 checks passed1 problem found
- lowTask runner
A Makefile / Taskfile gives a contributor a single index of the project's commands.
Fix: Add a Makefile / Taskfile collecting the common dev commands.
- 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.
- Pull-request template — A PR template tells a first-time contributor what a good change includes.
- 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.
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
3 checks passed1 problem found
- lowSecurity policy
A SECURITY.md tells a newcomer how to report a problem responsibly.
Fix: Add a SECURITY.md describing how to report a vulnerability.
- 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.
Where the grip slips
- highGetting Running+15 pts if fixed
Missing explicit dev setup instructions in root README or CONTRIBUTING
A newcomer cloning the repo has no clear path to go from 'git clone' to 'tests pass' without digging through package.json, .github/workflows, or the packages/svelte README. CONTRIBUTING.md is truncated in the visible snapshot and the root README doesn't cover Node version, pnpm version detail, or 'pnpm install && pnpm test' style steps. This forces trial-and-error on a multi-package workspace.
Fix: Add a 'Development Setup' section to the root README with: (1) Node and pnpm version requirements; (2) 'git clone && pnpm install' and 'pnpm test' example commands; (3) link to full dev instructions in CONTRIBUTING.md. Ensure CONTRIBUTING.md includes a detailed 'Getting Started for Contributors' section with dev environment steps.
- mediumFinding Your Way+12 pts if fixed
No architecture or compiler-phase overview for navigating the codebase
The compiler source tree shows clear phase boundaries (phases/1-parse, 2-analyze, 3-codegen, etc.) but no overview of how data flows through them or what each phase does. A newcomer diving into packages/svelte/src/compiler/ will see visitor patterns and AST structures without a map of the whole system. This makes it hard to locate where to make a change.
Fix: Create packages/svelte/ARCHITECTURE.md describing: (1) the three+ main compiler phases with examples; (2) how AST transforms flow through each phase; (3) key file layout (e.g., visitors/, errors, types); (4) links to relevant code and RFCs. Link from the main CONTRIBUTING.md and packages/svelte README.
- mediumPath To Contribute+10 pts if fixed
Truncated CONTRIBUTING.md in snapshot obscures full contributor workflow
The CONTRIBUTING.md excerpt ends mid-sentence in the 'Prioritization' section, so a newcomer reading it in the actual repo may miss later sections on code style, PR requirements, test coverage, or commit conventions—all critical for a low-friction first contribution.
Fix: Ensure CONTRIBUTING.md is complete and includes: (1) code style and lint commands (eslint/prettier are in package.json but not documented); (2) test expectations ('pnpm test' passes); (3) commit and PR conventions; (4) how to link RFCs and issues in PRs; (5) who to ask if stuck. Add a table of contents at the top.
- lowGetting Running+3 pts if fixed
No .gitignore or environment template for node_modules and build outputs
While .gitignore exists (shown in file tree), there is no .env.example or config template visible, making it unclear if the monorepo needs any non-standard environment variables or if pnpm install will work out of the box. For a compiler with benchmarking and release workflows, this is a minor but real source of friction.
Fix: If not already present, add a short .env.example (even if empty) documenting any optional env vars. Ensure root README has a 'Prerequisites' section confirming Node/pnpm versions and that 'pnpm install' is sufficient.
- lowGetting Running+2 pts if fixed
TypeScript version (^5.5.4) not pinned; could cause breakage for long-lived dev envs
package.json lists 'typescript': '^5.5.4', allowing minor/patch updates. For a compiler project where TypeScript versions matter (it appears in the compiler itself), this could silently introduce type checking inconsistencies or breakage when a dev hasn't touched the repo in months and re-runs pnpm install.
Fix: Pin TypeScript to an exact version (e.g., '5.5.4') or a conservative range (e.g., '~5.5.4'). Document the TypeScript version requirement in the dev setup section of CONTRIBUTING.md. Add a CI check to catch TypeScript version drift.
Show your score
[](https://latch.fyi/sveltejs/svelte)Share this analysis
https://latch.fyi/sveltejs/svelteFixed 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.