A mature, well-documented framework core with excellent contribution infrastructure, but setup complexity and fragmented developer instructions create friction for 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.
21 of 34 checks passed across 6 categories.
Machine Orientation
3 checks passed4 problems found
- mediumAgent instructions file
AGENTS.md / CLAUDE.md is the direct, machine-read channel for entry points and conventions.
Fix: Add an AGENTS.md naming the entry points, the build/test commands, and the house conventions.
- 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.
- lowTopics set
GitHub topics situate the repo's domain and stack for an agent at a glance.
Fix: Add a few GitHub topics describing the domain and stack.
- 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.
- Repository description set — The one-line description is the fastest orientation signal an agent reads.
- 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
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
5 checks passed3 problems found
- medium.gitignore covers env files
An ignore rule for .env is what keeps the next careless commit from leaking secrets.
Fix: Add `.env` (and `.env.*`) to .gitignore.
- 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 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
- 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).
- 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.
- 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.
73 / 10016 of 25 checks passed across 6 categories.
First Impression
82Clear purpose and mature signaling, but defers to external docs and lacks a concrete quick-start example.
The README immediately establishes Vue as a progressive JavaScript framework with badges showing maturity (npm stats, CI status). However, it punts almost all substance to vuejs.org without showing what the repository itself contains or why a newcomer might fork or clone it. A minimal working example in the README would transform this from 'please go read docs elsewhere' to 'here's what you can do with this repo.'
Getting Running
65Build and test scripts exist but require tribal knowledge about pnpm workspaces, prerequisite Node versions, and package structure.
The README offers no setup instructions—just 'follow vuejs.org docs.' The package.json reveals a pnpm workspace (pnpm@11.5.2 enforced) with Node >=20.0.0 required, but no newcomer sees this without digging. No DEVELOPMENT.md, no 'npm install && npm run dev' equivalent, and the scripts (e.g., 'node scripts/dev.js') are undocumented. A new contributor cannot deterministically go from clone to running tests without external guidance or reading build.js.
Finding Your Way
75Organized package structure and clear module boundaries, but no architecture overview or navigation guide.
The file tree shows a clean monorepo: packages/compiler-{core,dom,sfc}, packages/reactivity, packages/runtime-{core,dom}, etc. Naming is consistent and module purposes are inferrable. However, there is no ARCHITECTURE.md or overview explaining how these fit together, how data flows through the compiler, or where to start reading. A newcomer can navigate by folder names but will waste time reverse-engineering dependency chains.
Path to Contribute
78Dedicated CONTRIBUTING guide and issue templates present, but process is rigid and gated by commit conventions and maintainer approval patterns.
The repo links to .github/contributing.md and provides issue templates (bug_report.yml) and commit conventions (.github/commit-convention.md). It also routes support questions away from issues to keep the tracker clean. However, there are 983 open issues, no clear 'good first issue' labels visible, and the contributing guide is a single Markdown file (content unknown from snapshot). First-time contributors may find the formality daunting without seeing worked examples or beginner tasks.
Signs of Life
85Excellent maintenance signals: recent commits, active CI, clear release and changelog processes, and a large contributor base.
Last pushed 2026-06-15 (current), with a sophisticated release.yml workflow, renovate.json5 for dependency management, and extensive changelog history (CHANGELOG-3.0 through 3.4 plus main CHANGELOG.md). The README shows hundreds of contributors via opencollective widget. 53k+ stars and active sponsorship indicate a thriving project. This is clearly maintained and resourced.
Open Door
88MIT license and comprehensive maintainer infrastructure in place; missing explicit code of conduct.
LICENSE file and README both cite MIT clearly, making the repo legally reusable. The .github folder includes maintenance policies (maintenance.md), security guidelines (SECURITY.md), and detailed issue workflows. However, the snapshot shows no CODE_OF_CONDUCT.md, which is a minor but real gap for projects of this size. A newcomer can still ask for help (forum, community chat), but the absence of a CoC is a small social-safety miss.
First Impression
2 checks passed1 problem found
- lowTopics set
Topics situate the project's domain at a glance and help a newcomer find it.
Fix: Add a few GitHub topics describing the domain and stack.
- 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.
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
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
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
- 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).
- 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.
- Security policy — A SECURITY.md tells a newcomer how to report a problem responsibly.
Where the grip slips
- highGetting Running+15 pts if fixed
No DEVELOPMENT.md or setup guide—README defers all setup to external docs
A newcomer cloning the repo sees only 'follow vuejs.org docs' and no indication of how to install, build, or test locally. The package.json reveals pnpm, Node 20+, and build scripts, but no entry-level path is documented in the repository itself. This forces every new contributor to hunt for setup instructions or ask for help.
Fix: Add DEVELOPMENT.md (or expand README with a 'Local Development' section) documenting: (1) prerequisites (Node 20+, pnpm 11.5.2+), (2) install (pnpm install), (3) build (npm run build), (4) test (npm run test), (5) dev server (npm run dev), with copy-pasteable commands. Reference .github/contributing.md for deeper workflows.
- highFinding Your Way+12 pts if fixed
No ARCHITECTURE.md—mental map of 80+ packages unclear to newcomers
The monorepo contains compiler-core, compiler-dom, compiler-sfc, reactivity, runtime-core, runtime-dom, server-renderer, and many more. No document explains how they relate, what data flows from compiler to runtime, or where to start reading the code. A newcomer cannot distinguish between which packages are public API vs. internals or understand the dependency graph.
Fix: Create ARCHITECTURE.md with: (1) high-level diagram of compiler → runtime → DOM flow, (2) one-line descriptions of each core package (compiler-core, reactivity, runtime-core, etc.), (3) which packages are public vs. private, (4) how to navigate from a user question to the right module. Link from README and CONTRIBUTING.md.
- mediumFirst Impression+8 pts if fixed
README lacks a working code example—feels abstract for newcomers
The README explains nothing about what you can *do* with Vue by running the code in this repository. No example of compiling a component, using reactivity, or running a minimal project. It reads as 'this is important' rather than 'here's what you get.'
Fix: Add a 'Quick Example' section to README showing: (1) a minimal .vue component, (2) one line showing how to compile or run it from this repo (e.g., `npm run build && npm run dev`), (3) what output or behavior to expect. This gives newcomers immediate proof of what the repo does.
- mediumPath To Contribute+8 pts if fixed
Contributing guide not visible in snapshot; unclear contribution workflow for beginners
The README references 'Contributing Guide' at .github/contributing.md, but the snapshot does not show its content. Without seeing it, a newcomer cannot verify that the guide is beginner-friendly, includes examples, or labels 'good first issues.'
Fix: Verify .github/contributing.md includes: (1) step-by-step PR workflow (fork → branch → commit → PR), (2) commit message conventions with examples (link to .github/commit-convention.md), (3) test and lint commands (npm run test, npm run lint), (4) link to ARCHITECTURE.md for code navigation. If not, expand it.
- lowPath To Contribute+6 pts if fixed
No 'good first issue' labels or beginner task list visible
With 983 open issues, a newcomer has no signal for which issues are suitable for a first contribution. Many might be advanced compiler internals or edge cases.
Fix: Add 'good-first-issue' or 'beginner-friendly' labels to 5–10 small, well-scoped issues (e.g., doc fixes, small refactors, test coverage). Curate a list in CONTRIBUTING.md under 'Getting Started' pointing to these labels. GitHub's built-in tooling (https://github.com/vuejs/core/contribute) will then highlight them.
- mediumOpen Door+5 pts if fixed
No CODE_OF_CONDUCT.md—missing explicit social safety signal for large project
With 53k+ stars and hundreds of contributors, the absence of a visible code of conduct is a red flag for inclusive projects. Newcomers may hesitate to ask questions or report issues if there's no stated community standard.
Fix: Add CODE_OF_CONDUCT.md (e.g., based on Contributor Covenant) to the repository root. Link it from the main README and .github/contributing.md. This is table-stakes for projects of this scale.
- lowGetting Running+5 pts if fixed
Scripts in package.json lack inline documentation—npm run dev doesn't say what it does
Scripts like 'npm run dev', 'npm run build-dts', 'npm run dev-sfc' are terse and undocumented. A newcomer has no idea what 'dev-sfc-prepare' vs. 'dev-sfc-run' means or why they would use one over the other.
Fix: Add a 'scripts' section to DEVELOPMENT.md listing each npm script with a one-line description: 'npm run dev — start dev server for core, 'npm run test — run unit tests with vitest', etc. Or use a tool like ntl (npm task list) to make scripts self-documenting.
Show your score
[](https://latch.fyi/vuejs/core)Share this analysis
https://latch.fyi/vuejs/coreFixed 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.