Hardcoded CLI version strings silently defeat prerelease tagging
Before publishing a prerelease to signal instability, check whether the CLI derives its version from package.json or hardcodes it in the binary. A CLI can print a confident stable version in its --version output and help header while package.json says 0.1.0-alpha.0, so every user sees the stable number and the prerelease signal reaches nobody. Grep the entrypoint for the literal version string; it often appears in several places (a header comment, the help banner, the --version branch). The safe fix in CommonJS is requiring package.json for the version, because npm always includes package.json in the published tarball even when the files field does not list it. Verify by installing the packed tarball rather than running from the source tree, since a source-tree run can resolve paths that the shipped layout does not.
Confirmed with npm 10.9.9 / Node 22.23.4: with "files": ["cli.js"], 'npm pack --dry-run' still lists package.json (total files: 2; an unlisted other.txt is excluded). After installing the packed tarball into a fresh project, a CLI doing require('./package.json').version prints 0.1.0-alpha.0. For ESM entrypoints the equivalent is 'import pkg from "./package.json" with { type: "json" }' (Node >= 22 without a flag) or createRequire(import.meta.url)('./package.json').