npm ERR! Invalid version: "1" — make it full semver

TL;DR#

Invalid version: "1" means npm read a package.json whose version field is not a valid semantic version. npm wants all three numbers, major.minor.patch: "1" and "1.0" are rejected, "1.0.0" passes. Change the field to "1.0.0" in the file that carries the short version, by hand or with npm version 1.0.0 --no-git-tag-version.

The command that trips depends on the npm release. On npm 6 (tested: 6.14.12), npm start, npm pack and npm publish fail on the project's own file, and npm install fails when a dependency's package.json has the short version. On npm 8.19.4 and 11.19.0, install and start work and only npm publish (and npm pkg fix on 11) fails. That is how an app can run with node app on a laptop and die on a server.

The error#

The Stack Overflow question behind this page comes from a Google App Engine deployment in 2018. The app ran with node app locally, but on App Engine the instance was killed and the logs showed:

npm ERR! Invalid version: "1"

The deploy itself, started with gcloud app deploy --version=deploy, always ended with:

ERROR: (gcloud.app.deploy) Error Response: [4] Timed out waiting for the app infrastructure to become healthy.

The package.json posted in the question has "version": "1.0.0", so the "1" was in some other manifest npm read on the server; the question does not show which one. The answer with the most votes (15) found it in the project's own file: "version": "1", edited to "1.0.0", fixed it. The accepted answer instead suggested loosening the engines pins. A negative control below shows why the version field is the place to look first.

Why it happens#

npm's package.json documentation states the rule in one line: "Version must be parseable by node-semver, which is bundled with npm as a dependency." A semver version has three dot-separated numbers. "1" has one, so semver returns null for it and npm throws.

The throw lives in the code npm uses to normalise a manifest. Searching the npm installed in each test container for the message shows where it comes from:

node_modules/normalize-package-data/lib/fixer.js:191:      throw new Error('Invalid version: "'+ data.version + '"')
node_modules/@npmcli/package-json/lib/normalize.js:183:        throw new Error(`Invalid version: "${data.version}"`)

The first line is npm 6.14.12 (normalize-package-data); the second is npm 11.19.0 (@npmcli/package-json). The message is the same; what changed between releases is which commands run that check. The table below comes from a reproduction on 10 October 2026 in throwaway containers built from the official node:10-alpine, node:16-alpine and node:24-alpine images, with a minimal project whose package.json says "version": "1":

On npm 6 the install printed the message as a warning and carried on:

npm WARN Invalid version: "1"

and the next npm start stopped before running the script:

$ npm start
npm ERR! Invalid version: "1"

On npm 11 the same project installed and started; only the publish step refused it:

$ npm publish --dry-run
npm error Invalid version: "1"

Current npm prints npm error where npm 6 and 8 printed npm ERR!; the rest of the line is identical, so both spellings belong to this page.

Fix#

1. Find the file npm is reading. On your own project, look at the version line of the root package.json. If it already reads "1.0.0", as in the question, search the manifests of your dependencies, such as a local file: dependency (the case reproduced further down).

   bash

   grep -rnE --include=package.json '"version": *"[0-9]+(\.[0-9]+)?"' .

   Each hit is a package.json whose version has one or two numbers instead of three, such as "1" or "1.0".

2. Rewrite the field as major.minor.patch. Edit the file by hand:

   json

   {
     "name": "my-app",
     "version": "1.0.0"
   }

   or let npm write it, which worked on all three tested releases:

   bash

   npm version 1.0.0 --no-git-tag-version

   The flag matters in a git repository. The npm version documentation says: "If run in a git repo, it will also create a version commit and tag." Without the flag, fixing a typo becomes a release commit and a tag.

3. Do not reach for npm version patch here. It computes the next version from the current one, and the current one is the problem. With "1" in the file it fails on every tested release; npm 8.19.4 and 11.19.0 answer with a different message, which is easy to mistake for a second bug:

   text

   $ npm version patch --no-git-tag-version
   npm error Invalid version: patch

4. Do not count on npm pkg fix. The npm docs describe it as a command that "Auto corrects common errors in your package.json", but a bare "1" is not something it can correct. On npm 11.19.0 it stopped with npm error Invalid version: "1" and left the file unchanged; npm 8.19.4 did not have the subcommand at all.

5. Redeploy (or republish) once the file in source control carries the full version.

Verify the fix#

Run the command that failed, on the same npm release the server uses (npm -v there, not on your laptop). After the single change from "1" to "1.0.0", the reproduction went from a failure to a clean run on npm 6.14.12:

$ npm start
 
> ilb-invalid-version-demo@1.0.0 start /w
> node app.js
 
app started
exit=0

For a package you publish, npm publish --dry-run builds the tarball without uploading it. On npm 11.19.0 the dry run for the corrected file printed the version it would publish and exited with 0:

npm notice version: 1.0.0

When your own version is already 1.0.0#

The question does not show where the "1" came from; the reproduction shows two things worth checking.

A dependency's manifest counts too on npm 6. A project with a valid root version and one local dependency, "lib": "file:./lib", whose own package.json said "version": "1", failed at install time on npm 6.14.12:

$ npm install
npm ERR! Invalid version: "1"

The same project installed without complaint on npm 8.19.4 and 11.19.0. A host that installs with an older npm than your machine (the question's engines field asked for npm 4.2.0) can therefore fail on a manifest your own npm never complains about. The message does not say which file it read; the grep in step 1 does.

The engines pins are not what produces the message. The accepted answer suggested replacing "node": "6.9.4" and "npm": "4.2.0" with ranges. As a negative control, a project with a valid "1.0.0" version and exactly those two pins was installed and started on all three releases. npm 8.19.4 and 11.19.0 printed an EBADENGINE warning and npm 6.14.12 printed none; on every release npm start ran the app:

npm warn EBADENGINE Unsupported engine {
npm warn EBADENGINE   package: 'ilb-invalid-version-demo@1.0.0',
npm warn EBADENGINE   required: { node: '6.9.4', npm: '4.2.0' },
npm warn EBADENGINE   current: { node: 'v24.21.0', npm: '11.19.0' }
npm warn EBADENGINE }

That only covers the releases tested here; npm 4.2.0 itself was not run. Loosening the pins can still be worth doing for a hosted runtime, but it does not touch a version string semver cannot parse.

Which short versions npm forgives#

Not every non-standard version fails: npm cleans some spellings instead of rejecting them. In the same containers, npm publish --dry-run gave:

• "1.0": rejected on all three releases, Invalid version: "1.0".
• "v1.0.0" and "01.0.0": accepted and cleaned to 1.0.0. npm 11.19.0 said so out loud with npm warn publish "version" was cleaned and set to "1.0.0" and asked for npm pkg fix; npm 6.14.12 and 8.19.4 cleaned it silently.
• "1.0.0-beta": a valid prerelease. npm 6.14.12 and 8.19.4 accepted it; npm 11.19.0 stopped with a different error, You must specify a tag using --tag when publishing a prerelease version.

The rule in the docs is that node-semver must be able to parse it; in practice, write major.minor.patch with an optional prerelease suffix. Anything shorter is a bug waiting for the first command that validates it.

After the version is fixed#

On npm 6, the same install that used to print Invalid version will still print a few npm WARN lines for missing metadata, for example No repository field. for a project with no repository entry. Those are warnings, not the next failure; npm WARN package.json: No repository field explains them and the one-line "private": true that silences them for an application. If the deploy now gets past npm but the app still dies on the platform at start-up, compare what the platform installs with what your start script needs: on Heroku, a start script that calls babel-node fails because the devDependencies are pruned after the build. And if the platform's install stops on a peer range instead, that is a different resolver error, covered in npm ERESOLVE with a Firebase prerelease. Once every manifest npm reads carries a major.minor.patch version, this particular message has nothing left to point at.

Further reading: Fix "No license field" when package.json has a license. Also see Fix npm ENOTEMPTY: directory not empty, rename. Also see Fix npm ERR! Unexpected token '.' with nvm-windows. Also see npm install stuck on idealTree buildDeps: find the stall.