vue-router: what the official Vue.js router actually does, and where it stops

What vue-router solves, and who is actually supposed to use it

A Vue application that renders more than one screen needs a way to map a URL to a component tree, keep browser history coherent when the user presses back, and expose the current location to components that need it. vue-router is the package that does this. The repository describes it as the official router for Vue.js, which matters less as a badge and more as a maintenance fact: it lives in the vuejs organisation, its releases are cut from this repository, and its documentation is hosted at router.vuejs.org. The audience is Vue developers. If you are writing a Vue single-page application, a server-rendered Vue app, or a desktop shell around Vue, this is the layer that turns a component tree into something addressable. If you are not using Vue, the package has nothing to offer you, because its integration points are Vue's plugin and component systems. The README itself is thin: a sponsors block, a link to the documentation, a link to an in-browser playground, one install command, a contributing guide, and a note that the Security Policy file lists supported versions. That thinness is a signal about where the project expects you to learn it.

How the routing layer is put together in this repository

The repository is a pnpm workspace. The root package.json is named @vue/router-root, marked private, and declares workspaces as packages/*. That means the publishable router code and the documentation site are separate workspace packages, and the root scripts fan out across them with pnpm run -r. The docs pipeline is visible in those scripts: docs:api runs typedoc before docs:build runs the docs package build, so the API reference is generated from types rather than hand-written. The netlify script builds packages/router first and then the docs, which is the order a static deploy needs. The root also carries build:size and a size script built on brotli, so bundle size is measured as part of the project's own tooling rather than left to users. Linting is oxlint plus oxfmt, tests run through vitest with a Playwright browser provider configured, and TypeScript is pinned at ~6.0.3. None of this tells you how routing behaves at runtime; the README does not describe the matching algorithm, the history implementations, or the navigation guard order. What the repository layout does tell you is that the router is developed as a typed, tested, size-checked package alongside its own documentation.

Installing vue-router and getting one route on screen

The README gives exactly one install command, and it targets the major version explicitly. Run it in an existing Vue project:

npm install vue-router@5

After that, the README does not walk through registration, route definitions, or the router view component. It points at the documentation and at an in-browser playground, and those are where the remaining steps live. The honest summary is that this repository is not a tutorial. If you want to evaluate vue-router without touching a local project, the README's playground link is the fastest path, because it runs the router in a browser tab with no install. For a local project, the install line above is the only command the README commits to, and everything after it should be read from router.vuejs.org rather than reconstructed from the repository files. The root package.json does define a play script that runs across workspaces, but that is a contributor entry point for this monorepo, not a user-facing command, and the README does not present it as one.

Where the documentation stops and you are on your own

The README's most consequential omission is scope. It never states which Vue versions a given vue-router release supports. It delegates that to packages/router/SECURITY.md, which the README links as the place to see currently supported versions. That is a reasonable split for a mature project, but it means a reader who only opens the README cannot answer the compatibility question that decides whether an upgrade is safe. The same applies to migration: releases v5.2.0, v5.3.0 and v5.3.1 appear in the release list, and the README says nothing about what changed between them or how to move across major versions. If you are planning an upgrade, the README will not help you and the Security Policy file will only tell you what is supported, not what breaks. The second limitation is category confusion. The repository name is router, and the related search data shows that most people searching that word want networking hardware, woodworking tools, or a car. Nothing in this repository addresses any of that. If you arrived here looking for a device, this is the wrong project and no amount of reading will change that.

Choosing between vue-router and a framework-agnostic router

The real alternative is a framework-independent router such as a general-purpose client-side routing library that you wire into Vue yourself. The difference is not features, it is coupling. A framework-agnostic router gives you a history abstraction and a matcher, and you write the glue that turns route changes into Vue reactivity, that registers navigation guards in Vue's lifecycle, and that handles server-side rendering. vue-router removes that glue by being a Vue plugin, which is why its install command can be a single npm line and why its API surface can assume Vue's component model. The cost of that choice is portability. If you later move the same routing logic to another framework, the framework-agnostic router survives and vue-router does not. For most Vue projects that trade is obviously worth taking, since the glue you would write by hand is the part most likely to be subtly wrong. For a codebase that shares routing between two frameworks, or that treats Vue as one of several renderers, the agnostic option is the one that keeps the routing layer stable while the view layer changes.

Maintenance, releases and what the MIT licence means here

The repository is not archived, and the last push was on 2026-09-22, one day before the date used for this assessment. Recent releases are v5.3.1 on 2026-09-02, v5.3.0 on 2026-08-27, and v5.2.0 on 2026-07-15. That cadence, combined with the workspace scripts for release, size checking and API docs generation, describes a project that ships on a regular schedule. The licence is MIT, which is permissive: it allows use, modification and redistribution, including in closed-source products, provided the copyright notice and permission notice are preserved. It does not grant trademark rights, and it provides no warranty. If your organisation has a policy about which open source licences are acceptable for shipped dependencies, MIT is usually on the allow list, but that is a policy question for your legal team and not something this repository decides. On upgrade cost, the practical issue is the one the README leaves open: the supported-version matrix lives in packages/router/SECURITY.md, so an upgrade plan should start there rather than from the README or the release list.

Editorial conclusion

Adopt vue-router if you are building a Vue application and want the routing layer maintained in the same repository as the framework's own tooling, under MIT. Do not adopt it if you are searching for a hardware router, a woodworking jig, or a framework-agnostic router; nothing here addresses those. Before committing, read packages/router/SECURITY.md, which the README names as the place that lists currently supported versions, and check that your Vue version matches the release you install, since the README's only install command pins vue-router@5.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. vuejs/router on GitHub