reveal.js 6.0 is a TypeScript and Vite project whose README is 137 words of links

The README describes eight capabilities and shows none of them

Count the words and the README comes to 137. It opens by calling reveal.js an open source HTML presentation framework that enables anyone with a web browser to create beautiful presentations for free, and it points at the live demo. After that, the feature paragraph is a list of links: nested slides, Markdown support, Auto-Animate, PDF export, speaker notes, LaTeX typesetting, syntax highlighted code, and an extensive API. Each phrase is a hyperlink to its own page on the documentation site.

There is no installation command in the file, no HTML snippet, no JavaScript snippet, and no configuration example. The Getting started section is five links, of which one is to an installation page, one to the demo presentation, one to the documentation, one to a graphical editor at Slides.com, and one to a paid video course.

That is a defensible choice for a project with a documentation site, and it is also a real obstacle. Every capability the framework advertises is described by the sentence naming it and nothing else, so a reader cannot tell from the repository what Auto-Animate does, whether Markdown support covers the extensions you use, or what the API surface looks like. Anyone evaluating this framework has to leave the repository to evaluate it, and the material in this repository is the project description rather than the project documentation.

index.html ships inside the package, which makes it the real tutorial

The files array in package.json is more interesting than a default. It publishes dist, css, js, LICENSE, README.md, index.html and demo.html. Two complete HTML documents are in that list, alongside the code, and both exist at the repository root too.

That is the answer to the previous problem. The documentation site is where the features are explained, but the minimum working presentation is in the tarball. Opening index.html after npm install reveal.js shows the script tags, the stylesheet link and the container element a deck needs, in a form that runs, and demo.html is the fuller version with the features switched on. Copying index.html and editing it is a faster path to a first deck than following a written tutorial, and it is a path the package layout clearly intends.

The same list also tells you what you will not get. The examples directory is not published, so the fourteen example files at the repository root are available by clone but not by install. Neither is the plugin source, the test directory, the react directory or the build directory. The published surface is the built framework, the styles, the raw js tree and two example documents, which is a clean surface for a consumer and a thin one for anyone who wants to see how a feature is put together.

The exports map names six plugins and a theme wildcard

Version 6 is a dual-format package. The type field is set to module, the main entry points at dist/reveal.js for CommonJS, the module field at dist/reveal.mjs, and the types field at dist/reveal.d.ts. The root export repeats those four conditions, with default falling back to the CommonJS build.

From there the map becomes specific. Two stylesheet subpaths are exposed directly, ./reveal.css and ./reset.css, and a wildcard exposes ./theme/* against the same path under dist, so a theme is imported by name rather than by a hard-coded file. Then six plugins each get their own entry with types, import, require and default conditions: highlight, markdown, math, notes, search and zoom. Highlight additionally exposes a stylesheet at ./plugin/highlight/monokai.css, which tells you the syntax highlighter ships a named colour scheme as a separate importable file rather than as a bundled stylesheet.

For a bundler user this is the part that matters. Nothing needs a path alias, nothing needs a global script tag, and a theme is a variable rather than a filename. The constraint is the flip side: those six are the plugins the package map exposes, so a plugin that exists in the plugin directory but has no subpath entry has to be reached another way, and the map is the authoritative list of what a modern import can name.

Version 6 landed in March 2026 and no migration note exists in the repository

The release history has a clear shape. 6.0.0 shipped on 2026-03-11, 6.0.1 on 2026-04-11, and 6.0.2 on 2026-09-10. The repository's last push was on 2026-09-18, and package.json reads 6.0.2, which matches the newest release rather than the branch tip.

A major version in March means a 5.x to 6.x transition happened, and the README contains no mention of it. There is no upgrade section, no compatibility table, no deprecation list, and no changelog file at the repository root. The top level holds dotfiles, LICENSE, README.md, the build, css, demo.html, dist, examples, index.html, js, the package files, plugin, public, react, scripts, test and the TypeScript and Vite configuration, and nothing that records what changed at the major boundary.

The cadence is also worth noting for planning. Three patch-level releases in six months is a slow, deliberate rhythm rather than a continuous one, so a behaviour you rely on is unlikely to change weekly and unlikely to be fixed quickly either. If you are coming from 5.x, the migration information has to come from the documentation site or the issue tracker, because the repository will not tell you what broke.

500-slides.html and barebones.html mark the two ends of the supported range

The examples directory has fourteen entries and they are not a feature tour, they are a set of boundary tests. barebones.html is the floor: the smallest deck that runs, with nothing but the framework. 500-slides.html is the ceiling, a deck five hundred slides long, which is the case that breaks naive implementations that assume a slide list fits comfortably in the DOM.

Between those sit the cases that are awkward rather than large. auto-animate.html covers the transition feature the README links by name. markdown.html and markdown.md are a pair, showing the Markdown entry point alongside the file it reads, so you can see which side of the conversion you are editing. math.html covers LaTeX typesetting, media.html covers audio and video, backgrounds.html covers per-slide backgrounds, and transitions.html covers the transition set.

Three more are structural. multiple-presentations.html covers the case of more than one deck in one page, scroll.html covers a scroll-driven mode, and layout-helpers.html and lightbox.html cover the markup conveniences. The set is a good diagnostic: if your use case is one of these fourteen shapes, the framework handles it in a form you can read. If it is something else, you are extending rather than configuring, and none of these files will show you how.

The free claim and the paid course sit three lines apart

The README states that reveal.js enables anyone with a web browser to create beautiful presentations for free, and it is true of the framework, which is MIT licensed with the copyright line reading 2011-2026 Hakim El Hattab. The paid surfaces are named in the same document, one section apart. The Getting started list includes a reveal.js video course marked paid, and a separate paragraph invites readers to a graphical editor at Slides.com, described as made by the same people behind reveal.js.

None of that is a problem in itself. Sponsoring or selling tooling built on an open project is how a lot of open source stays alive, and a visual editor is a reasonable thing for the author of a slide framework to want people to have. It matters for a reader because the two are not separated. There is no boundary in the README between what the MIT licence covers and what the commercial products cover, and someone arriving from a search result that promised free presentations has to work out for themselves which of the five Getting started links costs money.

The practical rule is simple enough to state. The framework, the themes, the plugins and the examples are covered by the MIT licence in the repository. The visual editor and the video course are separate products from the same author, and the MIT licence says nothing about either of them.

Two Vite configs and two tsconfig files, for a project written in JavaScript

The build setup is visible in the file names. There is a vite.config.ts and a vite.config.styles.ts, which split the JavaScript bundle from the stylesheet build, and a tsconfig.json alongside tsconfig.node.json, which is the usual split between the project configuration and the configuration for tooling that runs under Node. Formatting is handled by a .prettierrc with a .prettierignore, and spelling by a .codespellrc.

So the framework itself is written in TypeScript, or at least typed, while the package it publishes is consumed as JavaScript in three shapes: the CommonJS build at dist/reveal.js, the ES module build at dist/reveal.mjs, and a stylesheet. The types field points at a declaration file rather than at source, so a TypeScript consumer gets the same d.ts the package ships and never sees the implementation types directly.

For a contributor this is a well-organised repository with a build directory, a scripts directory and a test directory, and the roll of tooling is modern and coherent. For a user it means one thing worth checking before you start: because the stylesheet is a separate Vite build, a change to the CSS pipeline does not necessarily travel with a change to the JavaScript one, and a theme you customise is a separate artefact from the framework you version. Read the two Vite configs before you fork the styling.

Editorial conclusion

reveal.js fits a technical presenter who wants slides that live in version control next to the code they describe, and the exports map is clean enough that a bundler will resolve the framework, the reset, the theme and each plugin by subpath without a manual alias. It does not fit someone who needs to learn the framework from the repository, because the README is a list of eight links and no markup, and it does not fit a workflow that requires PowerPoint output, which the documentation does not mention. Before adopting it, open the index.html that ships inside the package and build your first deck from that file rather than from a tutorial, then check the theme wildcard and the six plugin subpaths in the exports map so you know which files you are allowed to import by name.

Frequently asked questions

Official sources

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