Vue 2 reached End of Life, and the repository still serves a 2.7.16 runtime

The exports map hands Node a different file than your bundler

The main entry point resolves three ways, and the third one surprises people.

"exports": {
  ".": {
    "types": "./types/index.d.ts",
    "import": {
      "node": "./dist/vue.runtime.mjs",
      "default": "./dist/vue.runtime.esm.js"
    },
    "require": "./dist/vue.runtime.common.js"
  }
}

Under the `node` condition an ESM import gets the `.mjs` runtime, while every other resolver falls through to the `.esm.js` build and a CommonJS `require` gets the `.common.js` build. Older tooling that ignores `exports` altogether falls back to `main`, which is `dist/vue.runtime.common.js`, and the `module` field points at the ESM build for bundlers that read that instead.

So the same `import Vue from 'vue'` can resolve to three different files depending on the resolver, and nothing in the package warns you which one you got. That matters for server-side rendering, where the Node condition is the one you want and a misconfigured resolver quietly hands the browser-oriented build to your server.

sideEffects: false lets your bundler delete the import that registered your plugin

One line in package.json carries more risk than the rest of the manifest combined.

"sideEffects": false

That tells a tree-shaking bundler that no file in this package has an effect when imported, so an import of a module from this package whose bindings you never reference is a candidate for deletion. The field describes the files of the vue package itself, not plugins you install from other packages.

Five watch targets, and none of them is the file npm serves

Development builds are a rollup watch with a TARGET value injected on the command line, and there are five of them.

"dev": "rollup -w -c scripts/config.js --environment TARGET:full-dev",
"dev:cjs": "rollup -w -c scripts/config.js --environment TARGET:runtime-cjs-dev",
"dev:esm": "rollup -w -c scripts/config.js --environment TARGET:runtime-esm",
"dev:ssr": "rollup -w -c scripts/config.js --environment TARGET:server-renderer",
"dev:compiler": "rollup -w -c scripts/config.js --environment TARGET:compiler "

Read the target names against the `files` array, which ships `dist/*.js`, `dist/*.mjs`, `types/*.d.ts`, `compiler-sfc`, `packages/compiler-sfc` and `src`. The plain `dev` script builds the `full-dev` target, and `dist/` appears at the top level of the repository.

One consequence: a server-side rendering change needs `dev:ssr` specifically, because nothing in the default watch covers the server-renderer entry. The full build is a separate script, `node scripts/build.js`.

v2.7.16 was named Swan Song, and the last push was 2024-10-10

The repository is not marked archived, so it stays clonable and the branch stays browsable. What the README's first heading says is that this is the inactive repository for Vue 2, and that current work on Vue happens in vuejs/core.

The dates back that up. End of Life was December 31st, 2023, and the project says it no longer receives new features, updates or fixes. The final release was v2.7.16 on 2023-12-24, titled Swan Song, after two betas earlier that month. The last push to the repository was on 2024-10-10.

No GitHub release follows 2.7.16, so a push dated 2024 does not imply a supported release. The version in package.json is also 2.7.16.

The issue list is exclusively for bugs, and anything off-guideline gets closed

The project states that the issue list of this repository is exclusively for bug reports and feature requests, and points questions to the official forum or community chat. There is a separate rule about what counts: read the Issue Reporting Checklist before opening an issue, and issues that do not conform to the guidelines may be closed immediately.

The policy itself is unremarkable. On a project whose last release was 2023-12-24 it has a different effect. A well-formed bug report against 2.7.16 is a well-formed request for a fix that will not come, and the guidance you get back is the forum, where the answer will be the migration guide.

The README's Changelog section points at the release notes for this repository, and the migration path it recommends is a different repository entirely, vuejs/core, with its own guide at v3-migration.vuejs.org.

Single file components arrive through a webpack loader and a subpath export

The `.vue` file is the reason most people reached for Vue, and the wiring for it is two separate pieces, only one of which the README lists in its ecosystem table.

One is vue-loader, described as the single file component loader for webpack. The README describes it as the single file component loader for webpack.

The other piece is the compiler, and it is exposed as its own subpath rather than through the main entry.

"./compiler-sfc": {
  "types": "./compiler-sfc/index.d.ts",
  "import": "./compiler-sfc/index.mjs",
  "require": "./compiler-sfc/index.js"
}

That subpath is why `files` includes both `compiler-sfc` and `packages/compiler-sfc`. Importing the compiler directly is the route open to tools that need to parse single file components without going through webpack.

Types are rolled up by api-extractor, so you cannot rebuild them with tsc alone

Type declarations are generated, then rolled up, then shipped. The whole sequence is one script.

"build:types": "rimraf temp && tsc --declaration --emitDeclarationOnly --outDir temp && api-extractor run && api-extractor run -c packages/compiler-sfc/api-extractor.json"

Read that left to right. A temp directory is destroyed, tsc emits declarations into it, and api-extractor runs twice, once for the main package and once against a second config for the single file component compiler. The repository root holds `api-extractor.json` and `api-extractor.tsconfig.json`, and the second run points at `packages/compiler-sfc/api-extractor.json`.

The shipped `typings` entry is `types/index.d.ts`. That is good for consumers and bad for contributors: you cannot reproduce the published types with tsc alone, and a contributor changing a public signature needs both api-extractor configs and the rollup step to see whether the change is compatible.

packageManager pins pnpm 8.9.2 while the build scripts still call npm

The manifest declares `"packageManager": "[email protected]"`, and the repository ships both `pnpm-lock.yaml` and `pnpm-workspace.yaml`. Then several scripts invoke npm.

The clearest one is the server-side renderer build, `"build:ssr": "npm run build -- runtime-cjs,server-renderer"`, which runs the build script through npm and passes two target names after the separator. The test script is composed the same way, chaining `npm run ts-check` into further sub-scripts.

This is a real trap for a contributor, because npm will happily run a script that assumes a pnpm-installed tree, and the resulting failure points at a missing module rather than at the package manager. A workspace with pnpm-lock.yaml, a pinned pnpm version and npm invocations inside its own scripts has no single source of truth for how it is meant to be installed. The pin tells you what the maintainer intends; the scripts do not enforce it.

Editorial conclusion

Keep Vue 2 only where a rewrite is genuinely blocked, and treat this repository as a read-only reference rather than a dependency you track. The package remains available on existing distribution channels, so nothing forces your hand today, but the last push was on 2024-10-10 and the last release was v2.7.16 on 2023-12-24, which means every defect you find from here is one you own. If a compliance or security review blocks unmaintained software, that review is the decision point, and the README points at Vue 2 NES as the option the project itself names. Before starting new work, check the exports map in package.json against your bundler's condition support, because that is where a Vue 2 install fails quietly rather than loudly.

Frequently asked questions

Official sources

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