Slidev shipped a major version four hours after a patch, and writes its version into three files

v52.20.0, v52.20.1, and the major v53.0.0 all shipped on 2026-09-16

The release timestamps are the interesting part. v52.20.0 was published at 00:24, v52.20.1 at 02:05, and v53.0.0 at 04:21, and the branch itself was last pushed at 04:20, so the major version landed within minutes of that commit. Three releases in under four hours, one of them a jump across a major version boundary. For a maintainer that is a normal release day. For anyone depending on the tool it has two consequences. A dependency written as latest or as a caret range can move you from a 52.x patch to a 53.x major without anyone changing your manifest, and the 52.20.1 fix is only in your build if you resolve to that exact version rather than to whatever supersedes it hours later. If your slides are tied to a plugin or a theme package, that boundary is where you find out whether the ecosystem around you has caught up.

One version number is written into three package.json files by a single bumpp call

The release script shows how the monorepo keeps its versions honest. One invocation is passed the root package.json, a glob over packages/*/package.json, and docs/package.json, with the --all flag and a post-bump hook that runs zx scripts/update-versions.mjs. Three locations in a single command, with the version update script run afterwards. The root package.json is marked private, so it is not itself published, which means the version a user installs as @slidev/cli comes from the package under packages/ while the number you read in the repository root is a copy. That duplication is the price of a workspace holding the CLI, the parser, the types, the VS Code extension, and the documentation site separately, all of which appear in the tree and in the dev dependencies as workspace references. It also means a hand edit to one of the three files leaves the published packages disagreeing with the root, and nothing in the build would necessarily complain, since the build resolves each package independently.

Shared dependency versions come from a pnpm catalog, and patched packages live in patches/

The dev dependency list is written in terms of catalogs rather than numbers. Entries appear as catalog:dev for the ESLint config, catalog:prod for the ni and MCP client packages, catalog:frontend for the shikijs markdown-it and antfu utils packages, and catalog:types for the type stub packages, while the first-party packages use workspace references such as @slidev/cli, @slidev/parser, and @slidev/types. pnpm 12.4.2 is the declared package manager and turbo drives the per-package build and dev tasks, so the catalog in pnpm-workspace.yaml is the single place where a shared version is decided. Alongside that sits a patches/ directory, which is where a locally modified dependency is committed. Together these two files are what stand between a routine dependency bump and a working build, and a contributor who updates a locked dependency without checking patches/ will find out whether a patch still applies.

The test script runs vitest, while Cypress and Taze configs sit uninvoked beside it

There are three test configurations in the tree: vitest.config.ts, cypress.config.ts, and taze.config.ts, plus a cypress/ directory with its own fixtures project and a test/ directory. The npm script called test is `vitest test`, and the aggregate verification is a chain of build, typecheck, lint, and test. So the default command runs the unit suite and nothing else. Cypress is reached through a separate script that opens its interactive runner, and the Cypress fixture project is started by a script that runs a dev server inside cypress/fixtures/basic, which is a real deck rather than a mock. Taze, the command line app tester, has a config and no script in the root package.json invoking it. For a contributor this means a green test run is not evidence about browser behaviour, and for anyone judging project health, the browser-level coverage is not visible from the script list.

The install path is a scaffolder, and the floor is Node 22.12.0 in two places

The documented way in is short. Install Node.js >= 22.12.0, then:

npm init slidev

That creates a project rather than installing a global command, and the artefact you will actually depend on later is the @slidev/cli package on npm. The Node floor is stated twice, in the prose and in the engines field of the root package.json, which requires >=22.12.0, so the two agree, but the granularity is worth noting since anything on 22.0 through 22.11 fails the check even though it is a 22. The online alternative is a hosted path at sli.dev/new, and the repository also carries three runnable demo decks under demo/, one of which, demo/composable-vue, is the source of a previous conference talk. The docs are published in six languages and there is a Discord at chat.sli.dev.

A skills/ directory and a .claude-plugin/ are in the tree, unmentioned in the overview

The top level carries a skills/ directory and a .claude-plugin/ directory alongside a .vscode/ directory, and the dev dependencies include the Model Context Protocol client package. Nothing in the feature list or the tech stack mentions any of them. Taken together they say the project has an agent-facing surface, which matters for a tool people run locally on their own machines and which will read and write their files. A user reading the overview learns about presenter mode, drawing, recording, and a VS Code extension, and learns nothing about what an agent integration is allowed to reach. The documentation for that surface is not in the repository's own overview either, so anyone assessing the tool for an automated workflow is working from the tree rather than from the description, and the MCP client sitting in dev dependencies tells you the capability is real even when the page does not.

The export list has three targets, and none of them keeps your deck interactive

Portability is advertised as export into PDF, PNGs, or PPTX. That is a complete list of what comes out, and it is a shorter list than the feature set going in. A deck can contain embedded Vue components, live code blocks that execute while you present, UnoCSS utilities, a drawing layer, presenter mode driven from a second window or a phone, Mermaid diagrams, and KaTeX equations, and those features are the reason to use the tool. None of that behaviour survives a trip through a static format, so a PDF or a PNG is a picture of the deck at export time and a PPTX is a re-rendering of the same. If the artefact has to remain a working deck afterwards, the deliverable is the repository and the Markdown, not the exported file, and the two have to be planned for separately.

plans/ in the root means design documents ship with the code

The repository is mostly what you would expect from a pnpm and turbo monorepo, with a few entries that are not. There is a plans/ directory, holding design material in the same tree as the implementation, next to a scripts/ directory driven by zx, a docs/ site built separately from the packages with its own netlify.toml, and a demo/ folder of three decks. There is also shim.d.ts at the root and a tsdown.config.ts for bundling. The plans directory is the one that changes how a contributor works, because the reasoning behind a decision is available in the same repository as the decision rather than in an archived discussion, which makes it possible to read why a package boundary sits where it does before you move it. It also means the repository grows a directory that has nothing to do with building the CLI.

Editorial conclusion

Slidev fits a developer audience whose decks contain code, because live coding, Shiki highlighting, Mermaid diagrams, KaTeX, and npm-distributed themes are things a general slide tool does not attempt, and the authoring loop is a Markdown file in your own editor. It does not fit a deck that has to stay interactive after you hand it over: the export targets are PDF, PNG, and PPTX, and presenter mode, drawing, recording, and embedded Vue behaviour have no representation in any of them. Two decisions to make before you start. Pin the version, because v52.20.0, v52.20.1, and the major v53.0.0 were all published on 2026-09-16 within about four hours of each other, so a floating dependency can cross a major boundary while you are not looking. And accept that the version lives in three package.json files at once, root, packages, and docs, kept aligned by one bumpp invocation rather than by hand.

Frequently asked questions

Official sources

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