Mature, well-documented project with excellent first-impression materials and clear contribution paths, but complex monorepo tooling and demanding environment setup are friction points for true newcomers.
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.
27 of 35 checks passed across 6 categories.
Machine Orientation
7 checks passed1 problem 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.
- 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.
- Architecture doc — An ARCHITECTURE doc hands an agent the module map instead of making it infer one.
- Contribution conventions are written down — A contributor guide is where an agent learns the branch, commit, and review conventions it must follow.
Reproducible Setup
6 checks passed0 problems found
- 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.
- Env template present — A .env.example tells an agent which configuration keys it must supply to run.
- Container or dev-container — A Dockerfile / compose / devcontainer removes 'works on my machine' from setup.
- Dev container — A .devcontainer gives an agent a one-command, fully-declared environment.
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
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
6 checks passed2 problems found
- highNo committed .env
A tracked real .env hands secrets to anything — including an agent — that reads the repo.
Fix: Remove the .env from history, gitignore it, and ship a .env.example instead.
- 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.
- 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.
- CODEOWNERS present — CODEOWNERS marks the 'don't touch without review' zones an agent should respect.
- Automated dependency updates — Dependabot / Renovate keeps dependencies patched without a human in the loop.
- .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
1 check passed3 problems found
- mediumDependencies not vendored in
A committed node_modules / vendor tree drowns the real signal an agent needs.
Fix: Remove the vendored dependency directory and gitignore it.
- lowGenerated / vendored files marked
A .gitattributes linguist marker tells tools (and agents) what to skip.
Fix: Mark generated/vendored paths in .gitattributes (linguist-generated / linguist-vendored).
- 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.
- Build output not committed — Generated dist/ · build/ output is noise an agent has to read past.
How ready the repo is for a human newcomer to understand, set up, and contribute.
82 / 10020 of 25 checks passed across 6 categories.
First Impression
92Outstanding README with clear dual-product positioning, feature highlights, and strong social signals (14k+ stars, active partnerships).
The README immediately communicates the project's purpose (type-safe router and full-stack framework), target audience (React and beyond), and key value propositions (end-to-end type safety, nested layouts, caching). Badges showing npm downloads, bundle size, and semantic releases signal maturity and active maintenance. Links to documentation and community (Discord, discussions, sponsors) are prominent.
Getting Running
68Clear high-level setup steps but demanding prerequisites and scattered build/run commands across multiple contexts create friction.
CONTRIBUTING.md specifies Node and pnpm installation, lists the install command (`pnpm install`), and mentions running examples with `pnpm dev`. However, the project is a monorepo with multiple sub-packages (React Router, React Start, Solid, Vue variants), and a newcomer must navigate to specific example directories to see working code—no single 'clone and run' entry point. The `.nvmrc` and `.npmrc` exist but aren't explicitly called out. No docker setup despite `.devcontainer` presence, and Playwright install requirement for e2e is mentioned late.
Finding Your Way
75Strong architecture artifacts and clear monorepo structure, but navigating the 10,700+ file tree and multi-framework variants is cognitively heavy without a newcomer guide.
The repo includes `_artifacts/` with domain maps and skill trees (helpful), clear separation into `packages/`, `examples/`, and `benchmarks/`. However, there's no overview document explaining the project architecture, which packages are core vs. optional, or why multiple framework variants exist. A newcomer looking at the file tree sees `react-router`, `react-start`, `solid-router`, `vue-router` but no explanation of their relationships or which to study first. The CONTRIBUTING.md tells you *how* to build but not *what* is being built.
Path to Contribute
80Explicit contribution workflow with CONTRIBUTING.md, issue templates, and build/test scripts, but no beginner-labeled issues or starter task guidance.
CONTRIBUTING.md covers setup, build (`pnpm build:all`), dev (`pnpm dev`), and directs to docs editing workflow. GitHub templates for bug reports exist (seen in `.github/ISSUE_TEMPLATE`). However, there's no CONTRIBUTING section on how to find a first issue, no 'good first issue' or 'help wanted' label guidance visible, and no explicit testing or PR review expectations. The script listing (`test:unit`, `test:e2e`, etc.) is voluminous and assumes comfort with Nx.
Signs of Life
88Excellent signals: recent push (2026-06-15), 594 open issues, semantic releases, active changeset workflows, and partner roster signal active development.
The repo shows a last-pushed timestamp mere hours ago, multiple unreleased changesets (`.changeset/` directory), workflows for bundle-size monitoring, PR validation, and releases, and a who's-who of infrastructure partners (Cloudflare, Netlify, Sentry). The 14k+ stars and active GitHub discussions link suggest community traction. However, no explicit evidence of response time to issues or PRs is visible in the snapshot.
Open Door
90MIT License is clearly stated, active community channels (Discord, discussions, sponsors), and governance structures in place, but no formal Code of Conduct visible.
The LICENSE file confirms MIT, README links to Discord and GitHub discussions, and sponsor button is present—all signals of a welcoming, open project. Changeset workflow and CODEOWNERS file suggest structured maintenance. However, no CODE_OF_CONDUCT.md is present in the snapshot, which is a standard safety signal for newcomers and is expected in projects of this maturity and size.
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
6 checks passed0 problems found
- 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.
- Env template present — A .env.example shows a newcomer exactly which settings they must fill in to run it.
- One-command environment — A Dockerfile / compose / devcontainer turns a fiddly setup into one command.
- One-click dev container — A .devcontainer lets a newcomer start in a cloud IDE with zero local setup.
- 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
- 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.
- Architecture / overview doc — An overview hands a newcomer the map instead of making them reconstruct it.
Path to Contribute
4 checks passed2 problems found
- lowPull-request template
A PR template tells a first-time contributor what a good change includes.
Fix: Add a PULL_REQUEST_TEMPLATE.md.
- 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.
- 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
3 checks passed0 problems found
- 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.
- Automated dependency updates — Dependabot / Renovate activity is a visible heartbeat of ongoing maintenance.
Open Door
2 checks passed2 problems found
- lowCode of conduct
A code of conduct states the social ground rules that make it safe to step in.
Fix: Add a CODE_OF_CONDUCT.md (the Contributor Covenant is the de-facto standard).
- 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.
Where the grip slips
- highFinding Your Way+12 pts if fixed
Missing architecture overview and package-relationship guide.
The monorepo contains React Router, React Start, Solid Router, Solid Start, Vue Router, Vue Start, and plugins, but there's no document explaining which is core, which are optional, how they depend on each other, or why a newcomer should care about each. Navigating 10,700+ files without this mental map is disorienting.
Fix: Create `ARCHITECTURE.md` or `PROJECT_STRUCTURE.md` with: (1) diagram or list of packages and their purposes, (2) dependency relationships (e.g., React Start depends on React Router), (3) recommended entry points for different use cases (e.g., 'start here if you want a client-side router' vs. 'start here if you want SSR'), and (4) link to it from README and CONTRIBUTING.md.
- highGetting Running+10 pts if fixed
No single 'clone and run' example; requires monorepo knowledge.
A newcomer who clones the repo sees 10,700+ files, must install dependencies globally, then navigate to `examples/react/basic` to see a working app. There's no zero-config starter example or instructions for getting from root to a running demo in < 5 minutes.
Fix: Add a 'Quick Start' section to README.md or CONTRIBUTING.md with: (1) explicit step-by-step path to a working example (`cd examples/react/basic && pnpm dev`), (2) expected output (e.g., 'visit http://localhost:5173'), and (3) optionally provide a standalone 'minimal' example at the repo root that doesn't require monorepo understanding.
- highOpen Door+8 pts if fixed
No Code of Conduct despite large community and maturity.
A 14k-star, multi-team project with active community channels (Discord, discussions) lacks a Code of Conduct, which is a basic safety signal for newcomers. This is a glaring omission for a project positioning itself as a welcoming ecosystem.
Fix: Add a CODE_OF_CONDUCT.md file (e.g., Contributor Covenant) at the repository root and link to it in README.md. Example: [Contributor Covenant](https://www.contributor-covenant.org/) provides a standard template.
- mediumPath To Contribute+8 pts if fixed
Build/test/dev commands assume Nx expertise; no beginner context.
package.json lists `pnpm run test:pr`, `pnpm run test:ci`, `nx affected`, and `nx watch`, but CONTRIBUTING.md doesn't explain what Nx is, why it's used, or how to interpret its output. A newcomer running `pnpm run test:ci` sees unfamiliar output and has no guide.
Fix: Add a 'Build & Test Basics' section to CONTRIBUTING.md explaining: (1) the project uses Nx for monorepo task orchestration, (2) basic commands: `pnpm dev` (watch), `pnpm build` (cached), `pnpm test:unit` (unit tests), `pnpm test:e2e` (integration tests), (3) where to find logs if a task fails, and (4) link to [Nx docs](https://nx.dev/) for deeper learning.
- mediumPath To Contribute+6 pts if fixed
No 'good first issue' guidance or beginner-labeled issues visible.
CONTRIBUTING.md tells you how to set up and build, but not how to find a suitable first issue. With 594 open issues, a newcomer has no filter or recommendation for where to start contributing.
Fix: Add a section to CONTRIBUTING.md titled 'Finding Your First Issue' with: (1) a link to [issues filtered by label](https://github.com/TanStack/router/issues?q=is%3Aopen+label%3A%22good+first+issue%22), (2) guidance on issue difficulty (e.g., 'look for issues marked "good first issue" or "help wanted"'), (3) suggestion to ask questions in the issue or Discord if stuck, and (4) optionally start labeling a few existing issues with 'good first issue' or 'documentation' labels.
- lowGetting Running+3 pts if fixed
Playwright E2E test dependency mentioned late; not in initial setup.
CONTRIBUTING.md mentions `pnpm exec playwright install` as a separate step under 'Install test dependencies,' which a newcomer might skip if they only plan to modify code, not tests. This can cause confusing failures later if they run the full test suite.
Fix: Move the Playwright install to the main 'Install dependencies' section with clear explanation: 'E2E tests require Playwright browsers (required for the full test suite):' and note that it's optional if only building/editing code. Alternatively, make `pnpm install` run this step automatically via a postinstall script.
Show your score
[](https://latch.fyi/tanstack/router)Share this analysis
https://latch.fyi/tanstack/routerFixed 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.