package.json Generator with Scripts and Presets
Every Node project begins with one file at the repository root. npm reads it for the package name and version, tooling reads it for scripts and entry points, and teammates read it to learn which command starts the app. This page fills that file in from a form you control: pick a preset, adjust the fields, press the generate button, and get JSON that npm accepts as written.
The build step checks npm naming rules, semantic versions, script names, and dependency ranges, then lists anything suspicious in red under the button. The JSON still prints while problems are listed, so you can fix one line and regenerate instead of starting over. Every step runs in this tab: no upload, no account, no round trip.
Generate a package.json in Your Browser
How It Works
Generation is a straight line from fields to file, with the checks sitting at the end of it. Each step below maps to one part of the card above, and nothing runs until the generate button is pressed.
- Load a preset if you want a head start. The five options cover a Node application, a React and Vite project, a TypeScript library, an Astro site, and a command line tool; each one fills every field on the card, and none of them runs the generator on its own.
- Enter scripts one line at a time as name=command. The first equals sign splits the line, so a command that itself contains equals signs stays intact. Dependencies follow the same idea with whitespace: a package name, one space, then the range, one pair per line.
- Press Generate package.json to run the checks. npm name rules, semantic version syntax, the 160-character description limit, script characters, empty commands, duplicate script names, and every dependency range are inspected, and each finding appears as a red line under the output while the JSON still builds.
- Copy the result or download it as package.json. The download link points at a local blob created only after a successful run, and the fixed filename drops straight into a repository root.
Before and After
name my-node-app
version 1.0.0
description A Node.js application
type module
main src/index.js
scripts start, dev, test
devDependencies eslint ^9.14.0
issues none{
"name": "my-node-app",
"version": "1.0.0",
"description": "A Node.js application",
"type": "module",
"main": "src/index.js",
"scripts": {
"start": "node src/index.js",
"dev": "node --watch src/index.js",
"test": "node --test"
},
"license": "MIT",
"devDependencies": {
"eslint": "^9.14.0"
}
}Use Cases
| Developer | Production | Workflow |
|---|---|---|
| First commit of a side project | Preset loaded, fields skimmed once | npm test runs the same way everywhere |
| Library cut over to ES modules | type module plus the exports map | types target shipped beside the import target |
| Dependency bump before a release | Range problems listed in red | Dist-tag ranges caught before publish |
| Internal package renamed | npm name rules checked instantly | Duplicate scripts reported by line |
Common Mistakes
- Leaving type set to module while the files still call require, or the reverse. Node throws a syntax error on the first load, and the fix belongs in package.json rather than scattered rename edits.
- Writing a dist-tag such as latest where a range belongs. The install then drifts whenever the tag moves, and this page lists the problem while still printing the file so you can see what npm would read.
- Letting a duplicate script name ship. JSON keeps the last write, so the earlier command disappears without a word, and the red issue line is the only place the collision shows up here.
- Picking a name with uppercase letters or spaces. npm rejects those outright, so the name check reports the exact rule broken long before an npm publish attempt fails on a build server.
Best Practices
- Keep start, test, and build present in every repository so npm test and npm run build mean the same thing on your laptop, a teammate's laptop, and CI.
- Commit the lockfile and let it pin the exact tree, while the ranges in package.json stay at caret notation for day-to-day updates.
- Fill description, license, and keywords before the first publish, and keep the description at or under 160 characters so search snippets are not cut off.
- Move long setup commands into scripts instead of README copy-paste blocks, because scripts are what CI, editors, and other people actually run.
Frequently Asked Questions
What does npm actually require inside package.json?
Name and version are the only two fields npm insists on, and a project without them cannot be packed or installed properly. Everything else here is optional context: description, license, keywords, scripts, and the three dependency sections. The generator skips fields you left empty instead of writing blank values, so the output only carries what you filled in. The five presets each provide a working set for a common project shape.
How does type module change what Node loads?
Setting type to module tells Node that .js files in this package are ES modules, so import and export statements work without renaming files to .mjs. With commonjs, require and module.exports are the rules, which is what older packages and tooling still expect. Node will not mix the two styles for one package, and the wrong choice surfaces as a syntax error on the first load. Pick the value right after scaffolding and leave it alone afterward.
What does the exports map do?
The exports field is a lookup table that tells Node and bundlers which file to load when someone imports your package. The checkbox writes an exports object with a single dot entry carrying your types target and import target, the usual shape for a library that ships type definitions. When exports exists, modern resolvers ignore main for deep imports, so every reachable file has to appear there. Small apps that are never imported as a package can leave the box unchecked.
Which version range belongs on a dependency?
A caret such as ^4.19.0 accepts any 4.x release above that point, a tilde such as ~4.19.0 stays inside 4.19.x, and an exact number accepts nothing else. Your lockfile records the exact tree either way, which makes caret ranges the normal choice for applications. Writing a bare dist-tag such as latest instead of a range is flagged here, because npm would pull different code every time the tag moves. Git, file, link, workspace, and http specs are accepted as written.
Which scripts are worth having in every project?
Start, test, and build cover most workflows: one command to run the thing, one to check it, one to produce output. Teammates then type npm test instead of remembering which runner a particular repo picked. This page flags script lines with no name, no command, unsupported characters, or a name defined twice, since JSON keeps only the last copy of a duplicate. Lifecycle names such as prepublishOnly pass through the same checks.
Where do keywords and the other metadata fields matter?
The npm website search leans on name, keywords, and description, so a package without them stays hard to find even when the code is good. The license field tells people what they may do with the code, and audit tools read it during reviews. Keep the description at 160 characters or fewer, because npm cuts search snippets at that length and this generator reports the overflow as an issue. All of these fields appear on the npm page for the package, so they are worth writing before the first publish.
Does any of my input leave the browser?
No. Preset loading, line parsing, validation, and JSON generation all run inside this tab, and the page sends no network request with your fields. Nothing is written to storage either, so an internal package name or private registry host disappears when you close the tab. The only download that happens is the package.json file you press for yourself.