reactour's root manifest says 0.0.1, its declared Node floor is 14, and its newest release is from 2022

The root manifest is version 0.0.1 and marked private

The root of the workspace carries a manifest with a name, a version and a private flag, and the version is 0.0.1. That is not a mistake to be corrected mentally, because the root package is the workspace container and is never published; the packages that ship live under a directory of their own and carry their own versions. What it does mean is that anyone opening the root manifest looking for the library's version finds a placeholder. The releases tell the real story, and the story has a gap. The newest release is version 3.0.0 from August 2022, its release title being a sentence about leaving something behind. Before that come two tags from 2020, one adding observable step properties and highlight selectors, one disabling the focus lock and rounding the mask. Then nothing, for four years, while the last push to the default branch is 2026-05-19.

The engine floor says Node 14 while the workspace pins React 19

Here is the contradiction worth checking before you install anything. The manifest declares its engines as a package manager of at least version seven and Node of at least version fourteen. Everything else in the same file belongs to a much later decade. The development dependencies pin React and its DOM renderer at a version nineteen release, the React types at nineteen, the testing library's React bindings at sixteen, the Vite React plugin at five, the task runner at two point eight, TypeScript at five point nine, the test runner at three, the formatter at three point eight, and the coverage provider for the V8 engine. The package manager is declared as a version ten release of a different manager entirely. So the engines field describes a project from 2019 and the toolchain describes one from 2026, and the engines field is the part nobody updates.

Four packages, and only one of them is the thing you install

The readme describes the package set the way a maintainer would: a tourist guide and a set of assistants. The main package is the guide itself, and it is the one that takes an array of steps and highlights the corresponding parts of your application, using the other packages to do it. The second is a mask, a component that highlights a chosen element or area of the viewport, which is the dark surface with a hole in it that every tour needs. The third is a popover, a component that attaches to an element or to a position in the viewport and shows content there. The fourth is a set of helper functions the other three use, which you would not install directly. A fifth entry in the list is not a package at all but an application: the live site where all of it is visible working. The structure is deliberate, and it means the mask and the popover are usable in whatever you build even if you never run a tour.

A Babel config, a Vite plugin and two test setup files

The root directory mixes two generations of JavaScript tooling, which is normal for a library that has been around for years and worth knowing if you hit a strange error. There is a Babel configuration file at the root, which belongs to the era before the current bundler-based test and build setup, and there is also a Vite plugin for React in the development dependencies. The test configuration is two files at the root rather than one, a setup file and a shared file, which suggests the workspace packages differ enough in their test environment that one file is not enough. The linting is also split: an ESLint configuration file and an ignore file, plus a Prettier configuration and a plugin that runs the formatter through the linter, so a formatting mistake fails linting rather than being caught by a separate check. Two sponsor images sit at the root, which tells you where the project's funding links in the readme point.

The release script builds everything except the documentation app

The scripts are a small lesson in how to keep publishing separate from building. The build, development, lint and test commands all fan out to a task runner rather than to a single package, and the development command runs with the cache disabled, in parallel, and with continue-on-error so one package failing does not stop the others. Formatting runs the formatter over TypeScript, JavaScript, Markdown and MDX in one pass. Versioning is delegated to a changeset tool with a dedicated directory of pending changesets, and the release command is a build filtered to exclude the documentation application, followed by publishing. That filter is the interesting part: the documentation site is not built during a release, which means it is built somewhere else. There is a deployment configuration file at the root, so the site is a separate deployment with its own build cycle.

Overrides pin React exactly and allow five packages to run scripts

The package manager configuration at the end of the manifest is the part a monorepo maintainer will care about most, because it is where the repository imposes its opinion on every workspace package. Three overrides are declared: React and its DOM renderer pinned to one exact version, and a validation library pinned to another. That means a workspace package asking for a different React range still gets this one, which is how a library keeps a single copy of the renderer in its tree and stops the well-known duplicate-React bug. The same configuration block also lists the five packages allowed to execute install scripts, including the Tailwind native binding, an image processing library, the JavaScript bundler's native parts, a resolver and one small compatibility shim. Everything else is denied by default, which is the safer half of the feature and takes one line to review.

One release title is a sentence and one tag lost its prefix

Small things in the release list tell you how the project is run. Two of the three most recent tags are titled as sentences rather than as descriptions, one about adding new step properties for observables and highlight selectors, one about disabling the focus lock and rounding the mask, and the third about leaving something behind, truncated with an ellipsis in the tag name itself. The prefixes are inconsistent too: the two 2020 tags carry a version prefix and the 2022 tag does not, which means anyone scripting a release lookup has to handle both forms. And the readme has a section for repository activity whose entire content is a generated widget, so in the text version of the file that section is empty. If you are judging whether the project is alive, the activity section will not help you; the push date will.

Editorial conclusion

reactour fits a React application that needs a guided walkthrough over real elements, where the highlight and the popover have to move and reposition as the user clicks, and where a full-screen highlight surface is something you would rather not build. It does not fit a codebase that cannot take four packages instead of one, since the library's structure is itself its API. Two things to check before you adopt it. How current it is for your React version, because there has been no release since 2022 while the workspace pins React 19, so you are testing a published-2022 library against a 2026 dependency tree. And whether the platform layer you need exists, because the focus-lock and rounded-mask features named in an old release note are the sort of detail that moves in a rewrite, and the only document covering current behaviour is the documentation site.

Frequently asked questions

Official sources

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