Skip to content
ZeroServer.tools

package.json Generator

Configure application manifests, custom scripts, and dependencies for modern JS/TS environments.

1. Project Metadata

2. Scripts (Name: Command, one per line)

3. Interactive Dependency Selector

Common Dependencies
Common DevDependencies
Add Custom Dependency
Active Dependencies List (Edit version inline or delete)
Regular Dependencies (3)
react
react-dom
zod
Dev Dependencies (2)
typescript
eslint

4. Advanced / Publishing Settings

Understanding package.json structure

A package.json file lives in the root directory of your Node.js application. It forms the manifest describing the metadata, entry points, lifecycle hooks/scripts, engine targets, and dependencies that structure your project dependencies.

Type Module: Declaring "type": "module" forces Node to evaluate files as ECMAScript Modules (ESM) using import/export statements instead of old CommonJS require() conventions.

Semantic Versioning (SemVer): The prefixes in dependency versioning describe update boundaries:

  • ^1.2.3 (Caret): Installs any minor/patch updates without breaking major version (e.g. up to 1.9.9).
  • ~1.2.3 (Tilde): Installs only patch updates (e.g. up to 1.2.9).
  • 1.2.3 (Exact): Locked strictly to that specific version.

Built and maintained by Meet Shah · Last updated

What this tool is used for

  • Producing a package manifest for a new project.
  • Getting the fields right for a package you intend to publish.
  • Adding standard scripts without remembering the conventions.
  • Producing a manifest to compare against an existing one.
  • Setting the module type deliberately rather than by default.

Frequently Asked Questions

What do name and version have to look like?
The name must be lowercase URL-safe text, optionally scoped as `@scope/name`, and 214 characters or fewer. The version must be valid semver — `1.0` is rejected where `1.0.0` is accepted.
What does type: module change?
It makes every `.js` file in the package an ES module, so `import` works and `require` does not. Without it files are CommonJS unless named `.mjs`. Setting it on an existing package is a breaking change for consumers.
Why mark a project private?
`"private": true` makes npm refuse to publish it. For an application, a website or anything internal that single field is the cheapest protection against an accidental `npm publish` of proprietary code.
What is the difference between dependencies and devDependencies?
Dependencies are installed for anyone consuming your package; devDependencies are not. Build tools, test runners and type packages belong in dev — putting them in the wrong list inflates every downstream install.
What does the engines field enforce?
By default nothing — npm warns and continues. It becomes a hard requirement with `engine-strict=true` in `.npmrc`, and most CI and hosting platforms read it to pick a runtime version, which is reason enough to set it.
Is main still the right entry field?
`main` remains the compatible fallback, but `exports` is what modern resolvers prefer and it also blocks deep imports into your internals. Publishing both covers old and new tooling.

Common errors and gotchas

  • Omitting `type`, which leaves the module system to a default that may not match your code.
  • Setting `main` to a file that does not exist after a build, which breaks every consumer.
  • Publishing without `files` or an ignore file, which ships the whole working directory.
  • Using a version range for a dependency that needs pinning, or the reverse.
  • Choosing a name already taken on the registry, which only publishing reveals.

Related Developer Utilities tools

Private & free — this tool runs entirely in your browser.

CloudwaysManaged cloud hosting on AWS, GCP & DO — from $11/mo.affiliate