GO — Healthy across the board

• Used by 1 trusted project: nuxt/nuxt
• Last commit 2d ago
• 30+ active contributors
• Distributed ownership (top contributor 33% of recent commits)
• MIT licensed
• CI configured
• Tests present

_{Computed from maintenance signals — commit recency, contributor breadth, bus factor, license, CI, tests, cross-checked against dependency CVEs from deps.dev and OpenSSF Scorecard}

A software project. See architecture tab.

Developers.

See activity metrics.

Standard open source risks apply.

Check recent commits.

Check README for instructions.

• package.json — Monorepo root configuration defining workspace dependencies, build scripts, and package manager pinning (pnpm@11.9.0).
• packages-private/dts-test — TypeScript definition tests ensuring type safety across all public APIs and component composition patterns.
• .github/commit-convention.md — Documents conventional commit format required for all contributions to enable automated changelog generation.
• .github/contributing.md — Primary contribution guide covering development setup, testing, and pull request expectations.
• eslint.config.js — Shared linting rules enforced across the entire codebase for code quality and consistency.
• .prettierrc — Code formatting configuration applied to all source files during build and CI.
• scripts/build.js — Core build orchestration script handling compilation of multiple packages into distributable formats.

• Monorepo Root (package.json, scripts/) (pnpm, Node.js scripts) — Orchestrates multi-package builds, defines workspace structure, and runs cross-package CI tasks.
  • Failure mode: Build or test failures propagate across entire workspace; broken orchestration blocks all packages
• TypeScript Definitions (packages-private/dts-test) (TypeScript, tsc) — Validates all exported types and composition APIs work as intended at compile-time.
  • Failure mode: Type regressions ship to users; IDE autocomplete and type inference break
• GitHub Actions CI (workflows/) (GitHub Actions, YAML workflows) — Automates testing, linting, type-checking, and releases on every commit and PR.
  • Failure mode: Broken tests or formatting bypass PR gates; broken releases ship broken versions
• Code Quality Enforcement (ESLint, Prettier) (ESLint, Prettier) — Enforces consistent code style and catches common bugs via static analysis.
  • Failure mode: Inconsistent code style, uncaught bugs, difficult review experience
• Distribution Build (Rollup, rollup.dts.config.js) (Rollup, TypeScript) — Produces ESM, UMD, and global distribution bundles plus type declarations for npm publishing.
  • Failure mode: Users receive broken bundles, missing types, or incompatible module formats

• Developer source code (packages/*/src) → TypeScript compiler (tsc) — TS files are type-checked and compiled to JavaScript
• Compiled JS + type definitions → Rollup bundler — Bundler combines multi-package output into ESM, UMD, and global formats
• Built distributions (dist/) → npm registry — Release workflow publishes bundles and types for end users
• Type definitions → dts-test validation — Type tests verify API compatibility and ergonomics before release
• Source code → ESLint + Prettier — Code quality and formatting checks enforce standards on every commit

Add a new TypeScript definition test for an API

1. Create a new test file in packages-private/dts-test/ following naming pattern {feature}.test-d.ts (packages-private/dts-test/{newFeature}.test-d.ts)
2. Import types from the core packages and write type-level assertions using expectType<> utilities (packages-private/dts-test/utils.d.ts)
3. Run type checking via 'npm run check' or 'tsc' to validate definitions (tsconfig.build.json)

Fix a code quality issue and commit it

1. Make changes to source files following the patterns in existing packages/*/src/ (packages-private/dts-test/package.json)
2. Run 'npm run format' to apply Prettier formatting rules (.prettierrc)
3. Commit using conventional format: type(scope): description (see commit-convention.md for details) (.github/commit-convention.md)
4. Push branch and create PR; CI will automatically lint and test via GitHub Actions (.github/workflows/ci.yml)

Build and test the entire monorepo locally

1. Ensure pnpm@11.9.0 is installed (enforced via packageManager field) (package.json)
2. Run 'npm run build' to compile all packages in packages/ using build.js orchestration (scripts/build.js)
3. Run 'npm run check' to type-check all TypeScript including dts-test definitions (tsconfig.build.json)
4. Run 'npm run lint' to validate code against ESLint rules defined in eslint.config.js (eslint.config.js)

• pnpm@11.9.0 — Monorepo package manager with strict dependency isolation and efficient disk usage via content-addressable storage.
• TypeScript — Provides static type safety across the entire codebase and enables comprehensive type definition testing via dts-test.
• Vite — Modern build tool for development tooling (playground) and optimized bundling with ESM-first approach.
• Rollup — Primary bundler for producing multiple distribution formats (ESM, UMD, global) and type declaration files.
• GitHub Actions — CI/CD automation for testing, linting, type-checking, and automated releases on every commit/PR.

• Monorepo structure (packages/*) instead of separate repositories

  • Why: Shared types, single release cycle, and coordinated development across related packages
  • Consequence: Requires careful dependency management and coordinated testing across all packages

• Type definition testing in TypeScript (dts-test) rather than runtime-only tests

  • Why: Catches type API regressions early and ensures type ergonomics for users
  • Consequence: Additional test maintenance burden but catches issues that runtime tests cannot

• Conventional commits with automated changelog generation

  • Why: Clear commit history and automated semver versioning enable predictable releases
  • Consequence: Requires discipline from contributors to follow commit format conventions

• Backend server or API implementation — Vue.js core is a frontend framework only
• Database abstraction layer — data persistence is application responsibility
• State management enforcement — leaves this to user implementation or libraries like Pinia
• Build tool itself — Vue provides compiler packages, not a primary build tool distribution

• Avg cyclomatic complexity: ~7 — Vue core handles complex reactivity system, virtual DOM diffing, and template compilation with intricate dependency tracking and lifecycle management.
• Largest file: packages-private/dts-test/ (1,200 lines)
• Estimated quality issues: ~2 — Strong type safety and CI enforcement (ESLint, Prettier, TypeScript checks on all PRs) maintain high code quality; main risk is type definition divergence from runtime.

• Missing type definition tests for new APIs (High) — packages-private/dts-test/: New public APIs lacking corresponding .test-d.ts files ship without type safety validation.
• Inconsistent commit message format (Medium) — .github/commit-convention.md: Non-conventional commits bypass automated changelog generation and make history unclear.
• Manual type declaration maintenance (High) — packages-private/dts-built-test/: Hand-written .d.ts files can diverge from source implementation and cause type regressions.

• scripts/build.js (Build performance & centralization) — Central build orchestration; any build config change affects entire monorepo build time.
• .github/workflows/ci.yml (CI/CD bottleneck) — Single CI pipeline gate for all packages; failure in one package blocks all PRs.
• packages-private/dts-test/ (Testing bottleneck) — Type definition tests must pass before release; complex types can slow test iteration.

Standard debugging applies.

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive TypeScript definition tests for the Composition API reactive utilities

The packages-private/dts-test directory contains TypeScript definition tests for various Vue features. However, based on the file list, there are limited tests for advanced reactivity patterns (computed, watch, watchEffect, reactive object mutations). This would improve type safety for a critical part of the framework and catch regressions in the DTS output.

• [ ] Create packages-private/dts-test/reactivityAdvanced.test-d.ts to expand on reactivity.test-d.ts
• [ ] Add test cases for computed with generic types and union types
• [ ] Add test cases for watch/watchEffect with multiple sources and complex callback signatures
• [ ] Add test cases for reactive object mutations and deep reactivity patterns
• [ ] Run 'npm run test-dts' to verify all tests pass

Add integration tests for SSR-specific edge cases in the E2E suite

The repo has a robust test structure (test-unit, test-e2e, test-dts) but examining the workflows and test config, there's opportunity to add specific E2E tests for Server-Side Rendering scenarios. Given Vue's importance in full-stack frameworks like Nuxt, SSR edge cases are critical.

• [ ] Create packages/vue/tests/e2e/ssr/ directory structure
• [ ] Add test file for hydration mismatch detection and error boundaries
• [ ] Add test file for async component behavior during SSR
• [ ] Add test file for directive handling in SSR context (v-show, custom directives)
• [ ] Run 'npm run test-e2e' to ensure tests execute properly

Add CI workflow for automated changelog entry validation in PRs

The repo has commit conventions (.github/commit-convention.md) and a changelog script (npm run changelog), but there's no automated CI workflow to validate that PR commits follow the convention or to warn contributors when changelog-relevant changes are missing. This would reduce maintainer burden and improve PR quality.

• [ ] Create .github/workflows/changelog-validation.yml workflow file
• [ ] Configure workflow to run on pull_request events
• [ ] Add step to validate conventional commit format using commitlint
• [ ] Add step to check if CHANGELOG.md was updated for user-facing changes (using commit message patterns)
• [ ] Add conditional warning/failure based on commit types (feat/fix require changelog consideration)
• [ ] Test workflow by creating a test PR with non-compliant commits

Check the issue tracker.

Vue.js/core demonstrates a reasonably mature security posture with a dedicated security contact (security@vuejs.org) and transparency about threat modeling decisions (XSS via templates). However, there are gaps in dependency verification, documentation completeness, and automated supply chain security scanning. The codebase itself appears well-maintained with active CI/CD workflows. Primary recommendations focus on enhancing documentation clarity, implementing stricter lockfile verification, and adding automated dependency vulnerability scanning to the development pipeline.

• Medium · Incomplete Security Policy Documentation — SECURITY.md. The SECURITY.md file appears to be truncated in the provided content. The Security Hall of Fame section is incomplete, cutting off mid-entry. This may indicate incomplete security documentation or potential missing vulnerability disclosure information. Fix: Ensure the SECURITY.md file is complete and fully documents the security vulnerability reporting process, response timelines, and all acknowledged researchers.
• Low · Template Expression XSS Disclaimer — SECURITY.md. While the project explicitly disclaims XSS via template expressions as a valid attack vector, this creates a potential security guidance gap. Users may misunderstand the distinction between intentional and accidental unsafe template compilation. Fix: Enhance documentation with clear examples of safe vs. unsafe template usage patterns. Consider adding warnings to APIs that accept template strings to guide developers away from dangerous patterns.
• Low · Missing Dependency Lock File Verification — package.json, .github/workflows/ci.yml. The package.json specifies pnpm@11.9.0 as the package manager but there is no visible verification mechanism documented for lockfile integrity in the provided CI/CD workflows. Fix: Implement lockfile verification in CI/CD pipelines (e.g., pnpm ci --frozen-lockfile) to ensure dependency integrity and prevent supply chain attacks.
• Low · No Visible SBOM or Dependency Scanning — Root configuration files. The repository structure shows no evidence of Software Bill of Materials (SBOM) generation or automated dependency vulnerability scanning tools like Snyk or npm audit. Fix: Integrate automated dependency scanning tools into CI/CD pipelines. Generate and maintain an SBOM for released versions to improve supply chain transparency.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/vuejs/core shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live vuejs/core repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/vuejs/core.

What it runs against: a local clone of vuejs/core — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in vuejs/core | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 32 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of vuejs/core. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/vuejs/core.git
#   cd core
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of vuejs/core and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "vuejs/core(\\.git)?\\b" \\
  && ok "origin remote is vuejs/core" \\
  || miss "origin remote is not vuejs/core (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "package.json" \\
  && ok "package.json" \\
  || miss "missing critical file: package.json"
test -f "packages-private/dts-test" \\
  && ok "packages-private/dts-test" \\
  || miss "missing critical file: packages-private/dts-test"
test -f ".github/commit-convention.md" \\
  && ok ".github/commit-convention.md" \\
  || miss "missing critical file: .github/commit-convention.md"
test -f ".github/contributing.md" \\
  && ok ".github/contributing.md" \\
  || miss "missing critical file: .github/contributing.md"
test -f "eslint.config.js" \\
  && ok "eslint.config.js" \\
  || miss "missing critical file: eslint.config.js"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 32 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~2d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/vuejs/core"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.