impress.js keeps extras/ in a submodule, and the manifest still reads 1.1.0 against a 2.0.0 tag

The manifest says 1.1.0 and the newest tag says 2.0.0

package.json declares `"version": "1.1.0"` and points its main entry at `js/impress.js`. The release history disagrees. The tags are v2.0.0 from 2022-07-22, 1.1.0 from 2020-04-11, and 1.0.0 from 2018-03-07. The repository is not archived and its last push is dated 2026-07-23, so commits are still landing, just not under new tags. The README is explicit that new features and fixes are continuously merged into the master branch, which is what the clone command checks out, and that the latest stable release is on the releases page instead. So what a plain clone cannot give you is the 2.0.0 release: the default branch is where unreleased work accumulates. The consequence is that the manifest version is a stale artifact rather than an indicator, so it tells you nothing about which release you are running.

A plain clone silently drops the extras plugins

The clone command in the README carries a recursive flag for a reason:

git clone --recursive https://github.com/impress/impress.js.git
cd impress.js

The note underneath says that for a minimal checkout you can omit the `--recursive` option, and that this will leave out extra plugins. That matches the repository layout, where `css/`, `examples/`, `js/`, `src/`, and `test/` are directories but `extras` appears as a submodule entry alongside a `.gitmodules` file. The plugins in `extras/` are also the ones not enabled by default, and you have to add them with their own `script` element to use them. So what a non-recursive clone cannot do is give you those plugins, and the failure is quiet because nothing errors, the file is simply not there. The consequence is that a contributor who clones without the flag and then tries a demo built on an extras plugin has to start over.

The file you link to is a concatenation, and the build is roughly a cat

The file a browser loads, `js/impress.js`, is generated rather than written. It contains a concatenation of the core `src/impress.js` and all the plugins, and the README describes the build as roughly `cat src/impress.js src/plugins/*/*.js > js/impress.js`. The `build.js` file produces that output and also produces a minified `impress.min.js`, with the note that the minified version is not included in the GitHub repository. So what this cannot do is hand you a minified build from the source tree without running the build first, and the committed file can drift from the sources it is generated from. The consequence is that a fix present in `src/plugins/` does nothing until someone regenerates `js/impress.js` and commits that too, which makes the pull request review two files for what is conceptually one change.

npm run all runs jshint and jscs and never reaches the eslint config

There are three linter configurations in the root, `.eslintrc.js`, `.jshintrc`, and `.jscsrc`, and two scripts that use them. The `all` script is `npm run build && npm run test && npm run lint`, and `lint` expands to `npm exec -- jshint src test/*.js && npm exec -- jscs src test/*.js`. The eslint configuration belongs to a separate `new-lint` script, `npm exec -- eslint src test`, which nothing in `all` calls. The contributor instructions say to run two commands, `npm install` and `npm run all`, so the default path is the jshint plus jscs pair. What this cannot do is give you a single standard, since a change can satisfy the enforced linters and still be rejected by the unused one. The consequence is that the name `new-lint` is the honest signal: the intended direction is eslint, and adopting it means changing what `all` runs.

The runtime needs no Node at all, which is the point of the package manifest

The manifest is described as having been added mainly so a developer can install buildify and run `node build.js`, with the explicit statement that apart from the build process and testing, impress.js itself does not depend on Node or any NPM modules. There is no runtime dependency block in the file at all; everything sits in devDependencies, from karma and its Chrome and Firefox launchers through qunit, syn, puppeteer, terser, and the three linters. The stated requirements are node 7.6 or newer plus npm. So what a presentation cannot require is a toolchain, since a deck is an HTML file and a script tag, and the same code runs from a CDN or a local file. The consequence is that the Node requirement applies to contributing, not to presenting, and the two are easy to conflate when you read the requirements list next to a build script.

The CSS in the repository styles the demo, not your slides

The `css/` directory holds a stylesheet used by the official demo, and the README states in bold that this file is not required for using impress.js in your own presentations, because impress.js creates the CSS it needs dynamically. That stylesheet is still worth reading, since it shows how the classes provided by impress.js are used, and the structure section points at it as the reference for styling. So what this cannot do is hand you a theme to apply, and copying it into your own deck is a common mistake that adds positioning and sizing rules you did not ask for. The consequence is that the look of a presentation comes from the transform and transition data in the HTML plus whatever CSS you write, which means the demo is a template to read rather than a stylesheet to import.

Two runners execute the same tests and the browser one is the recommended one

The test script is `npm exec -- karma start --log-level debug --single-run=true`, driven by `karma.conf.js` at the repository root with karma-qunit, karma-chrome-launcher, and karma-firefox-launcher. The root also holds `qunit_test_runner.html`, and the contributor note says that running `firefox qunit_test_runner.html` is usually more informative than running karma with `npm run test`, because both run the same tests. Tests live in `test/`, which carries the QUnit and Syn libraries, with per-plugin test directories inside each plugin. So what the headless runner cannot give you is the useful failure output, which is why the instructions point a human at a browser window. The consequence is that the test path assumes a local browser is present, and puppeteer at version 2.1.1 is in devDependencies as a second route to a headless one.

Editorial conclusion

impress.js fits someone building a browser-based deck who wants a single script tag and no build step at runtime, and who is comfortable treating the HTML of the demo page as the documentation. It does not fit a team that wants typed content pipelines, authoring inside a slide tool, or a release train to pin against, since tagged releases stopped at 2.0.0 in 2022 while commits continue on master. Before adopting it, clone with the recursive flag so the extras plugins are present, pin a CDN link to an explicit version rather than to source, and decide which of the three lint configurations you actually intend to enforce.

Frequently asked questions

Official sources

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