vuejs/core builds the vue package, and the repository is not the tutorial

The root package.json is private, so nothing here installs as a dependency

Start with the version field and you learn most of the shape of this repository. The root `package.json` sets `"private": true`, `"version": "3.5.43"`, `"type": "module"` and `"packageManager": "[email protected]"`, and the primary language of the source is TypeScript. A private package never reaches a registry, so the `vue` package your application imports is assembled from the `packages/` directory by a build script rather than installed from this root. One number ties the source tree to the published line: bumping `version` is the mechanism that moves the release, and the version you see in the file tracks the current release line rather than the most recent tag. A contributor checking out `main` is holding source for a version that may sit behind a tag, which is exactly why the first job in the contributing guide is reading that guide before opening a pull request.

One build script, and a size check that never fails anything

Every distribution shape comes out of `node scripts/build.js`, and the size targets sit on top of it rather than inside it.

"size": "run-s \"size-*\" && node scripts/usage-size.js",
"size-global": "node scripts/build.js vue runtime-dom -f global -p --size",
"size-esm-runtime": "node scripts/build.js vue -f esm-bundler-runtime",
"size-esm": "node scripts/build.js runtime-dom runtime-core reactivity shared -f esm-bundler"

Three angles are measured: a global build, the runtime alone, and the ESM bundler build of `runtime-dom`, `runtime-core`, `reactivity` and `shared`. What that cannot do is fail your build. The `--size` flag asks the build script to report, the run resolves through a promise chain after the size scripts, and no threshold for the reported figure appears in `package.json` or in the README. Bundle size therefore has to be watched by a human reading the output. It also says nothing about your application, because the numbers cover the framework and never the app code and dependencies that dominate a real bundle.

The browser end to end suite cannot start until a global build succeeds

Vitest carries the whole test surface, and the e2e path is gated behind a build.

"test": "vitest",
"test-unit": "vitest --project unit*",
"test-e2e": "node scripts/build.js vue -f global -d && vitest --project e2e --project e2e-browser",
"test-coverage": "vitest run --project unit* --coverage"

Coverage is scoped to the unit projects, so the e2e projects run with no coverage output. The e2e step asks the build script for a dev build in global format first, and the two vitest projects start only when that build exits cleanly. Fail the build and you learn nothing about browsers. In this repo an ordinary `npm test` is also a poor match for the scripts here, because the workspace expects [email protected].

Benchmark history lives in temp/, and the clean script deletes it

Comparisons in this project are local and temporary.

"prebench": "node scripts/build.js -pf esm-browser reactivity",
"bench": "vitest bench --project=unit --outputJson=temp/bench.json",
"bench-compare": "vitest bench --project=unit --compare=temp/bench.json",
"clean": "rimraf --glob packages/*/dist temp .eslintcache"

The measured baseline goes to `temp/bench.json`, and the comparison reads that same path back. `clean` removes `temp` along with `packages/*/dist`, so a cleaned checkout has nothing to compare against. The consequence for a reader is blunt: no performance number in the README, and no stored history of one, so nobody can show you a trend or reproduce a result after the fact.

Two release lines move a day apart, and only one of them is stable

Recent tags show two lines advancing at once. v3.6.0-rc.9 landed on 2026-09-18, v3.5.43 on 2026-09-17, and v3.6.0-rc.8 on 2026-09-11, and the last push to the default branch `main` was on 2026-09-25. Pinning the patch line gets you fixes and none of the 3.6 work, while a release candidate carries unfinished API in exchange for the newer surface. Nothing in the repository tells you how long 3.6 stays in rc, and the README does not carry a support window for any line. Which one you want is a decision about your own tolerance for churn, not something the changelog answers. `CHANGELOG.md` is generated from commit messages with the Angular convention, so what a release note says depends on how carefully the commit was written.

The 500 contributor wall comes from a GitHub image limit, not a headcount

Open any page of this repository and you will find funding wired through several separate files: `BACKERS.md`, `FUNDING.json`, a sponsor link in the README and a special sponsor slot currently held by betterstack.com. Development is presented as depending on that support. The contributor graph makes the opposite kind of claim and quietly fails to make it, because the README states that the graph shows the first 500 contributors only, due to GitHub image size limitations. The image is a truncated view of the contributor base, so any argument you build on its size is an argument about a GitHub rendering constraint. A large number of contributors also does not tell you how many will pick up a stale issue.

Support questions and bug reports go to different places, and one of them closes issues

The issue tracker here is a narrow gate. Questions and support are routed to the forum at forum.vuejs.org and community chat at chat.vuejs.org, and the README states the issue list is exclusively for bug reports and feature requests. The new issue helper at new-issue.vuejs.org applies, and the README warns that issues not conforming to the guidelines may be closed immediately. Plan the split yourself: how you use the framework is a forum question, and only a reproducible defect belongs in the tracker. Opening a usage question here risks an instant close and a slower route to an answer.

What you can do after cloning, and what the checkout will not hand you

The README sends every newcomer to the documentation at vuejs.org and stops there, with no install command, so this repository is where you work on Vue rather than where you pick it up. For a contributor, the entry points are the workspace scripts: `pnpm` is the declared package manager, and `pnpm build` runs `node scripts/build.js`, `pnpm dev` runs `node scripts/dev.js`, and type checking is `tsc --incremental --noEmit`.

"dev": "node scripts/dev.js",
"build": "node scripts/build.js",
"check": "tsc --incremental --noEmit",
"lint": "eslint --cache .",
"format-check": "prettier --check --cache ."

Two gaps are worth knowing before you start. The e2e path bundles `vue` in global format, while the `esm-bundler` format needs a bundler that rewrites imports to Vue's runtime helpers, and the README does not spell out that second step, so a fresh checkout has no application to run the framework in. The repo also pins a Node version in `.node-version` without stating it in prose, so a mismatched runtime shows up as a failed install rather than a clear message. Nothing about SSR, router, state stores or the dev server belongs here; those live in their own repositories.

Editorial conclusion

Adopt vuejs/core as a source of truth when you patch the framework, audit its internals or file a bug against internals, and read CONTRIBUTING.md first. Do not point an application project at it: the private root package, the [email protected] pin and the missing build step make it a workspace, not a dependency. If your work is a Vue application, the decision is which documented path at vuejs.org to follow, not which version of this repository to clone. Before filing anything, check the dates on the two release lines, since v3.5.43 and a v3.6.0 release candidate were both cut within days of each other.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes