package.json Generator

Build a Valid package.json Without Memorizing the Field Names

Running npm init gets you a bare-bones file, and then you're back to copying scripts and dependency blocks from your last project. This generator gives you a form for everything that actually matters — name, version, entry point, scripts, dependencies, dev dependencies, license, and module type — and builds valid, properly-formatted JSON as you type, ready to drop straight into a new project.

How to use it

• Fill in the package name, version, description, and entry point.
• Pick a license, or choose "UNLICENSED" for a private/proprietary project (also check the "Private" box so npm publish refuses to run by accident).
• Choose CommonJS or ES Modules — this sets the "type" field, which controls whether Node treats your .js files as require() or import syntax.
• Add scripts (start, build, test, lint, whatever you run) and any dependencies or dev dependencies with their version ranges.
• Copy the JSON or download it directly as package.json.

Real-world use cases

Starting a new Node project from scratch and wanting a complete, correct package.json in one pass instead of editing it field by field over the first hour. Setting up a small internal tool that should never accidentally get published to the public npm registry. Standardizing the scripts section (dev/build/test/lint) across several repos so every project in a team runs the same commands.

Frequently asked questions

What's the difference between dependencies and devDependencies?

dependencies are packages your app needs at runtime (like Express or React). devDependencies are only needed while developing or building — test runners, linters, bundlers — and aren't required once the app is built or deployed.

What does "type": "module" actually do?

It tells Node.js to treat .js files in the package as ES Modules, so you write import/export instead of require/module.exports. Leave it as CommonJS if your codebase (or its dependencies) still expects require().

How do I stop a package from being published to npm by accident?

Set "private": true — npm refuses to publish any package with that flag set, which is exactly what you want for internal tools and app repos that were never meant to be a public package.

What version format should I use for dependencies?

A caret range like ^1.4.0 is the npm default and allows updates that don't bump the major version. Use ~1.4.0 to only allow patch updates, or an exact version with no prefix to pin it completely.

Do I need a "main" field if I'm using ES Modules?

Yes, main still points to your package's entry file either way — it's what runs when someone does require('your-package') or import 'your-package'. Larger projects with dual builds sometimes add exports on top of it, but that's a manual edit outside the scope of this generator.