Package JSON Scaffold Generator

About this tool

Package.json Scaffold Generator on UtilityKit creates a minimal package.json for a new Node.js project. Enter a package name, version and optional description, then pick a license (MIT, ISC, Apache-2.0, GPL-3.0 or UNLICENSED), a module type (module or commonjs) and a scripts preset. Basic Node adds start, dev (node --watch) and test (node --test); Web app (Vite) adds dev, build and preview; Library build adds build (tsc), clean (rimraf dist) and prepublishOnly; None leaves scripts empty. The name is lowercased with unsupported characters turned into hyphens, and a version that is not in x.y.z form falls back to 1.0.0. The output is valid JSON with name, version, description, type, scripts and license, updates as you type, and shows line and byte counts. Add dependencies, engines, main or private yourself after copying, or let npm install add dependencies for you.

Why use it

• Valid JSON Every Time: The file is built with JSON.stringify, so there are no trailing commas, unquoted keys or missing braces.

• Runnable Script Presets: Basic Node uses Node's built-in --watch and --test flags, so npm run dev and npm test work without extra packages.

• Module Type Up Front: Choosing module or commonjs at the start avoids confusing import and require errors later.

• Name and Version Checks: Names are normalised to lowercase npm-friendly characters and invalid versions fall back to 1.0.0.

• Small, Readable Output: Only six fields are written, so the file is easy to review and extend.

How to use

1. Enter the Package name; it is lowercased and characters other than letters, digits, dots, underscores and hyphens become hyphens.
2. Enter a Version in x.y.z form (anything else falls back to 1.0.0) and an optional Description.
3. Pick a License and a Module type: module writes "type": "module" for ES modules, commonjs writes "type": "commonjs".
4. Choose a Scripts preset: None, Basic Node, Web app (Vite) or Library build.
5. Click Copy output, save the text as package.json in your project root, then run npm install <package> to add dependencies. Reset restores the defaults.

When it helps

• When bootstrapping a new Node.js service, CLI tool or library and you want a valid package.json without copying from a previous project.
• When starting a Vite web app by hand and you want the dev, build and preview scripts in place.
• When teaching Node.js fundamentals and you want a short package.json to explain field by field.
• When you need to decide between ES modules and CommonJS and want the type field set from the start.
• When preparing a small TypeScript library and want build, clean and prepublishOnly scripts as a starting point.

Examples

Name: My REST API, Version: 0.1.0, Description: Small REST API, License: MIT, Module type: commonjs, Scripts: Basic Node

{
  "name": "my-rest-api",
  "version": "0.1.0",
  "description": "Small REST API",
  "type": "commonjs",
  "scripts": {
    "start": "node index.js",
    "dev": "node --watch index.js",
    "test": "node --test"
  },
  "license": "MIT"
}

Name: my-lib, Version: 1.0 (invalid, falls back), License: ISC, Module type: module, Scripts: Library build

{
  "name": "my-lib",
  "version": "1.0.0",
  "description": "",
  "type": "module",
  "scripts": {
    "build": "tsc -p tsconfig.json",
    "clean": "rimraf dist",
    "prepublishOnly": "npm run build"
  },
  "license": "ISC"
}

Name: @myorg/shared-utils, Version: 0.0.1, License: UNLICENSED, Module type: module, Scripts: Web app (Vite)

{
  "name": "myorg-shared-utils",
  "version": "0.0.1",
  "description": "",
  "type": "module",
  "scripts": {
    "dev": "vite",
    "build": "vite build",
    "preview": "vite preview"
  },
  "license": "UNLICENSED"
}

Tips

• Add `"private": true` to your `package.json` if the package is not intended for npm publishing. This prevents accidental `npm publish` and suppresses irrelevant npm audit warnings about missing public registry fields.
• Use `npm pkg set scripts.prepare="husky"` after generating to wire up git hooks automatically on install — pair with the `husky` devDependency to enforce lint-staged checks on every commit.
• Set `"sideEffects": false` in library packages to enable tree-shaking in bundlers like Webpack and Rollup, reducing consumer bundle sizes.
• List `node` and `npm` version ranges separately in `engines` (e.g. `"node": ">=20"`, `"npm": ">=10"`) to catch version mismatches in both the runtime and the package manager.
• Run `npm pkg fix` after pasting the generated file into your project — it validates and normalises fields like `name` (converts to lowercase kebab-case if needed).

Frequently Asked Questions

Glossary

Semantic versioning (semver)

A versioning scheme with MAJOR.MINOR.PATCH numbers. Breaking changes increment MAJOR, new backwards-compatible features increment MINOR, bug fixes increment PATCH. npm uses semver ranges in dependency fields.

devDependencies

npm packages required only during development and build (linters, test runners, compilers). They are excluded from production installs and should not be needed at runtime.

engines field

A `package.json` field declaring the Node.js and npm versions the package is supported on. npm warns on version mismatch; `--engine-strict` makes it an error.

Caret range (^)

An npm version range prefix (e.g. `^9.0.0`) that allows updates to any compatible minor and patch version within the same major, helping projects receive bug fixes without breaking changes.

ESM (ES Modules)

The ECMAScript standard module system using `import`/`export` syntax. Enabled in Node.js by setting `"type": "module"` in `package.json`, replacing the older CommonJS `require()` system.

Lifecycle script

A special npm script name (e.g. `prepare`, `postinstall`, `pretest`) that npm automatically runs at defined points in the package install and publish lifecycle without being explicitly called.