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.

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