Package.json Generator

package.json
Next

Rather than running npm init and answering eleven prompts, fill in a form and get a tidy, correctly structured package.json back. This generator covers the required fields (name, version), the commonly-used ones (scripts, dependencies, devDependencies, engines), and the niceties (repository, bugs, keywords, license) that make a package discoverable and publishable.

How to generate your package.json

  1. 1

    Enter name and version

    Name follows npm rules: lowercase, URL-safe, under 214 chars. Version is semver (e.g. 0.1.0).

  2. 2

    Pick the module type

    CommonJS (default) or ESM via "type": "module". Matters for Node.js 14+ projects.

  3. 3

    Add scripts

    Start, build, test, lint: the commands run with `npm run <name>`.

  4. 4

    List dependencies

    Runtime packages in dependencies, tooling in devDependencies.

  5. 5

    Set metadata

    Description, author, license, repository URL, keywords.

  6. 6

    Copy the output

    Paste into a new package.json at the project root.

The fields that matter most

Field Required? Notes
name Yes Lowercase, 1-214 chars, URL-safe
version Yes Semver (major.minor.patch)
type No “module” for ESM, omit for CommonJS
main Recommended Entry point for CommonJS (index.js)
exports Recommended Modern exports map for dual CJS/ESM
scripts Strongly recommended npm run <name> commands
dependencies As needed Runtime packages
devDependencies As needed Build tools, test runners, linters
engines Nice to have Required Node version range
license Yes for publishing SPDX identifier like MIT, Apache-2.0

Semver cheat sheet

  • 1.0.0, major.minor.patch
  • ^1.0.0, compatible with 1.x.x (>=1.0.0, <2.0.0)
  • ~1.0.0, patch updates only (>=1.0.0, <1.1.0)
  • >=1.0.0 <2.0.0, explicit range
  • 1.0.0-beta.1, prerelease
  • latest, npm tag, not a version

Default when running npm install package is ^, which allows non-breaking upgrades.

Standard scripts worth having

{
  "scripts": {
    "start": "node index.js",
    "dev": "nodemon index.js",
    "build": "tsc",
    "test": "vitest",
    "lint": "eslint .",
    "format": "prettier --write ."
  }
}

Naming gotchas

  • No capitals. MyPackage fails npm install.
  • No spaces. Use hyphens: my-package.
  • Scoped names start with @org/ for GitHub or npm organisations: @acme/utils.
  • Reserved words. node_modules, favicon.ico, core, express can’t be used as package names.

License options

Pick a recognised SPDX identifier:

  • MIT, most permissive common choice.
  • Apache-2.0, permissive with patent grant.
  • ISC, very short MIT-like license, npm default.
  • GPL-3.0-or-later, copyleft.
  • UNLICENSED, private package, not for distribution.

Wrong or ambiguous license strings trigger warnings on npm publish.

Frequently Asked Questions

Dependencies are installed when someone runs npm install in a project that consumes yours. devDependencies are only installed in the package’s own development environment. Put runtime packages in dependencies and test/build tooling in devDependencies.

Yes, for applications. The lockfile pins exact versions and ensures reproducible installs across machines and CI. For library packages published to npm, the lockfile is optional, consumers get their own lockfile.

Only if you want the package to be ESM (import/export syntax) by default. Without it, .js files are treated as CommonJS. You can also use .mjs for ESM files or .cjs for CommonJS files regardless of “type”.

The Node versions your code has been tested against. A typical choice today is "engines": {"node": ">=18"}. It is a warning, not an error, but tooling respects it and users pin correctly.

Related Tools

Tool available in other languages