How to contribute

This section is the working guide for contributing to vuejs/core. It is condensed from .github/contributing.md, .github/commit-convention.md, .github/maintenance.md, and the conventions the source code itself enforces.

If you are starting from zero, read these in order:

1. Development workflow — branches (main vs minor), commit messages, PR expectations.
2. Testing — Vitest projects, where to put tests, how to run them.
3. Patterns and conventions — __DEV__ branches, NOOP, treeshaking rules, error handling, internal-API conventions.
4. Debugging — local debugging recipes via the SFC Playground, Template Explorer, and runtime-test.
5. Tooling — build scripts, CI workflows, size reports.

What kinds of PRs are accepted

The contributing guide is explicit about scope. In summary:

• Bug fixes are welcome when the bug is clearly reproducible (a linked issue or an in-PR repro). A PR title that says "fix bug" without explaining what is being fixed will be closed.
• New features are accepted only with a widely applicable use case. Vue's API surface is already large; anything that can be done in userland is unlikely to be merged. Non-trivial additions should go through the RFC repo first.
• Chores (typos, comment fixes, build/CI tweaks) should be combined into a single PR per area when possible.
• Stylistic refactors are explicitly discouraged. Code readability is subjective; the maintainers prefer the established style and won't review pure-style PRs.

The bug-repro-guidelines.md file in .github/ describes the standard for a good bug repro: an isolated SFC playground link or a minimal Vite repro.

Branch model

The repo uses two long-lived branches:

• main — patch releases (3.5.x). Bug fixes go here.
• minor — feature work for the next minor version (3.6 at time of writing). New API surface, performance refactors that touch many files, and breaking-ish changes go here.

The git-branch-workflow.png diagram in .github/ shows the merge flow. PR authors should target the right branch. See development workflow.

Commit message format

Vue uses Angular's commit convention. Every commit is validated by scripts/verify-commit.js against:

/^(revert: )?(feat|fix|docs|dx|style|refactor|perf|test|workflow|build|ci|chore|types|wip)(\(.+\))?: .{1,50}/

So a commit looks like fix(reactivity): preserve identity when unwrapping refs (#1234) or feat(compiler-sfc): support type-only props default value. Scopes are free-form but follow the package or feature being touched (core, compiler, ssr, v-model, transition, …).

Only feat, fix, and perf show up in the changelog. Breaking changes are flagged with BREAKING CHANGE: in the footer.

Definition of done

Before requesting review:

• pnpm check passes (also enforced as a pre-commit hook).
• pnpm lint is clean.
• pnpm test run is green for tests touching the affected packages. For wide changes run the whole suite.
• New behavior has a Vitest test under the appropriate __tests__/ directory.
• For features, accompanying type tests under packages-private/dts-test/ if the public type signature changes.
• Allow edits from maintainers is enabled on the PR (the maintainers frequently squash-fix small issues directly).

Where to look for unfamiliar areas

• The renderer (packages/runtime-core/src/renderer.ts) is intentionally one large file. The processing functions are arranged as processX / mountX / patchX, branching on ShapeFlags. New logic usually slots into the matching processX branch.
• The reactivity layer is small but dense. Read packages/reactivity before changing tracking or scheduling.
• The compiler is a pipeline. New compile-time behavior is almost always a new NodeTransform or DirectiveTransform plugged into compiler-core or compiler-dom.
• SFC <script setup> macros all share the ScriptCompileContext from packages/compiler-sfc/src/script/context.ts.

Maintenance philosophy

The .github/maintenance.md document describes how Evan You and the core team run the project: bug triage, RFC steering, size budgets, and release cadence. Worth a read before opening a non-trivial PR.