package.json Generator

Free package.json Generator with Framework Presets

A package.json file is the manifest at the root of every Node.js and npm project. It names the package, pins its dependencies, defines the scripts your team runs a hundred times a day, and tells Node whether to treat your code as ESM or CommonJS. This generator builds one field by field, shows the resulting JSON live as you type, and lets you copy or download the finished file. Everything runs in your browser — no registry calls, no account, nothing uploaded.

It is aimed at three situations: starting a project without running npm init and then editing the result, assembling a manifest for a stack you set up rarely enough that you have to look up the dependency names, and checking the exact shape of a field you half-remember. Fourteen presets — React, Next.js, Express, a Node CLI, a testing stack, Tailwind CSS, Prisma, authentication, UI components, forms, state management, linting and formatting, and a Turborepo monorepo — each merge in their dependencies and scripts without wiping what you already added.

How to Use the Generator

1. Fill in the basics. Package name, version, description, entry point, license, author, repository, keywords, and the minimum Node version.
2. Choose module type and privacy. module for ESM or commonjs for require(). Leave private on for anything you are not publishing to npm.
3. Apply presets. Open the Presets tab and click any combination. Presets merge: applying React and then Testing Stack and then Linting gives you all three sets of dependencies and scripts, and duplicate entries are skipped rather than added twice.
4. Add anything missing by hand. Dependencies take a name and a version range and a dev/production toggle; scripts take a name and a command.
5. Copy or download. The output pane shows formatted JSON with two-space indentation. Copy it, or download it directly as package.json.

Two details of the output are worth knowing. Dependencies and devDependencies are sorted alphabetically, which is what npm itself does and what keeps diffs readable. Empty fields are omitted entirely rather than written as empty strings, so you get a clean manifest rather than one padded with blanks.

package.json Field Reference

Version Range Syntax

The version string next to each dependency is a range, not a fixed version, and misreading it is one of the most common sources of surprise upgrades. The Reference tab in the tool lists these; here they are with worked bounds:

The caret is npm’s default because semantic versioning promises that minor and patch releases are backwards compatible. That promise is not enforced by anything, which is why a lockfile matters: the range in package.json describes what you accept, while package-lock.json records what you actually installed. Commit both. If you need to reason about which range a specific version satisfies, the semver calculator evaluates the comparison directly.

One special case catches people out: for versions below 1.0.0, the caret is much stricter than it looks. ^0.2.3 allows 0.2.x but not 0.3.0, because pre-1.0 packages are assumed to break on every minor bump.

ESM versus CommonJS

The type field decides how Node interprets a .js file. With "type": "module" you write import pkg from 'package' and top-level await works; with "type": "commonjs" or the field omitted, you write const pkg = require('package'). The extensions .mjs and .cjs override the field on a per-file basis, which is the usual escape hatch when a project has to contain both.

The practical consequence: an ESM package cannot be loaded with require() from CommonJS code without a dynamic import(). Publishing a library that a mixed audience can consume means either shipping both builds and describing them through an exports map, or picking one and stating it clearly.

Scripts Worth Standardising On

Consistent script names across repositories mean a new contributor never has to read the manifest to find out how to start the project. The conventional set is dev for the development server, build for a production build, start to run that build, test for the test suite, lint for the linter, format for the formatter, and typecheck for a no-emit TypeScript pass. The presets in this generator use exactly those names.

Two npm behaviours are worth remembering. npm test and npm start work without the run keyword, while everything else needs npm run <name>. And pre and post prefixes still fire automatically — a prebuild script runs before build without any wiring.

Frequently Asked Questions

Does this replace npm init?

It covers the same ground with a visual form and adds framework presets, but the two are complementary. npm init -y is faster if you want a stub to edit; this generator is faster when you want a complete manifest with the right dependencies already listed and correctly split between production and dev.

Are the dependency versions in the presets current?

The presets carry version ranges that were reasonable when they were written, and they are starting points, not a live registry feed. Run npm outdated after installing, and check release notes before accepting a major bump.

What is the difference between dependencies and devDependencies?

Dependencies are needed for the code to run and are installed for anyone who installs your package. devDependencies are only needed to build, test, or lint, and are skipped by production installs. Bundlers, test runners, linters, and type definitions belong in devDependencies; a web framework your server imports at runtime does not.

Why did the types field not appear in my output?

The generator only emits types when your dependency list includes typescript or a package starting with @types/. Pointing at a declaration file that a JavaScript-only project never produces would just be misleading, so the field is omitted.

Should I set private: true?

Yes, for every application and every internal package. It makes npm publish refuse to run, which is a cheap guard against publishing proprietary code to the public registry by accident. Turn it off only when you genuinely intend to publish.

What does the engines field actually enforce?

By default, npm prints a warning on mismatch and installs anyway. It becomes an error if engine-strict=true is set in .npmrc. Many hosting platforms and CI images read it to pick a Node version, which is the main reason to keep it accurate.

Can I use the output with pnpm or Yarn?

Yes. The manifest format is shared across npm, pnpm, Yarn, and Bun. Only the lockfile differs, and each tool generates its own on first install. Workspace configuration syntax differs slightly between package managers, so check that field if you are building a monorepo.

Is the file I build sent anywhere?

No. The whole generator is client-side JavaScript. The JSON is assembled in your browser, and the copy and download actions use your own clipboard and filesystem. Nothing reaches a server.

What should I do next after generating the file?

Save it as package.json, run npm install, then add a .gitignore with the .gitignore generator so node_modules and your .env stay out of version control, and create that .env with the .env file generator.