Install from npm, once published

Français · How-to · Published, reviewed by a person · Applies from: 4.2.5

The engine is not published on npm. On 23 Oct 2026, npm view answers 404 Not Found for quest-n-click, create-quest-n-click, quest-n-click-bridge, quest-n-click-connectors and quest-n-click-studio-server. Until a release's notes say otherwise, install from the release archive: Install from the release archive. This page says how to tell when npm is ready, and what the commands will be then.

Audience, context, and the statuses of what this page rests on

Audience: author · Context: created project

What you get

Today: a way to check, in one command, whether a quest-n-click package on npm is the project's. Once the packages are published: a game project created and upgraded with npm's usual commands, without an archive URL.

Context and versions

A created project, on your machine.
Nothing has ever been published to npm, up to and including 4.4.0. 4.2.0 went to GitHub Releases only (D38): publishing needs the maintainer's two-factor authentication at each step, and 4.2.0 did not wait for it. The README says npm publishing comes in a later release; no version is promised.
Until the first publication, the names are only watched: a job of the nightly workflow (npm-names, never gating) checks that each name, the current ones and the former web-scumm… ones, is still free or published by the maintainer's npm user, and warns otherwise. Someone else taking a name first is a risk the project accepted (D34).

Limit · npm-not-published No npm install quest-n-click, npx create-quest-n-click or npm install quest-n-click@<version> works today: npm answers 404. A package under one of these names that appears on npm before a release announces it is not the project's: do not install it.

Prerequisites

The Requirements of any game project: Node.js 22.12 or newer, Python 3 for the art.
A release whose notes announce the npm publication.

Where to run the commands

On your machine, from the folder that will contain the project; then inside the created project.

Steps

Check that the package exists and is the project's. Its maintainer must be wanoo and its repository github.com/wanoo/quest-n-click:
```
# anywhere
npm view quest-n-click maintainers repository.url
```
Today this prints npm error 404 Not Found: stop here and use the release archive.

Create the project. Either command does the same thing (create-quest-n-click runs quest-n-click create from the engine it depends on):
```
# in the folder that will contain the project
npx create-quest-n-click my-game "My Game"     # or: npx quest-n-click create my-game "My Game"
```
Without --engine, create writes the dependency "quest-n-click": "^<version>", which npm resolves from the registry.

Install, prepare the art and play, as from the archive:

# from the folder that contains the project, then inside it
cd my-game
npm install
python3 -m pip install -r node_modules/quest-n-click/requirements.txt
npm run assets && npm run dev

Expected result, and how to check it

Once published, step 1 prints the maintainer and the repository; step 2 ends with my-game: "My Game" created (quest-n-click ^<version>). A project made from an archive moves to the registry with npm install quest-n-click@<version>, which replaces the archive's URL in its package.json by a version range.

Common errors

Symptom	Cause	Fix
`npm error 404 Not Found - GET https://registry.npmjs.org/quest-n-click`	Not published yet	Install from the release archive
`npm view` shows a maintainer other than `wanoo`	A name taken by someone else	Do not install it; report it on the project's issues

Files or data changed

Step 1 changes nothing. Steps 2 and 3 write the same project as from the archive; only the dependency in package.json differs (a range instead of a URL).

Recovery or going back

A project created from npm goes back to an archive with npm install <archive URL>, as Upgrade describes.

How the publication is prepared

The procedure was written in 4.1.20 and is played by the maintainer in a later release; the details are on npm packages. What a user can rely on:

Staged publishing with a person's approval. The release run stages each package through GitHub's OIDC (trusted publishing, configured stage-only: CI may stage, never publish), and the maintainer promotes each one with two-factor authentication (npm stage approve <id>, or on npmjs.com). A version of the product never comes from a local publication, which would carry no OIDC provenance; only a reservation version 0.0.0-bootstrap.0 may, once per package, to create it.
Exact tools. Staged publishing needs npm 11.15.0 and Node 22.14.0 at least. release.yml pins the publishing step's versions exactly, NPM_PUBLISH_NODE: 22.23.3 and NPM_PUBLISH_NPM: 11.21.0, and a test refuses a range. Node 22.23.3 ships npm 10.9.9, so the step will install npm 11.21.0 itself. At 4.4.0 only the pins exist: the publishing step itself is not written yet.
The connectors are not declared dual-use. npm's dual-use policy covers tools that can resemble malicious software (penetration testing, security research, obfuscation); the connectors are servers a game runs (an SSH and a Telnet front, an email webhook and IMAP reader, an Open Badge verifier), scanning, attacking and hiding nothing. They go through the same staged publishing and two-factor promotion as the other packages. If npm's scan holds or flags the package, it gets "contentPolicy": { "class": "dual-use" } and a DISCLOSURE file.

References

Install from the release archive, Package reference
npm packages (the maintainer's procedure), Releasing
npm's documentation: staged publishing, dual-use policy
.github/workflows/nightly.yml (the npm-names job), .github/workflows/release.yml (the pins)

Edit the source of this page · Report an error