Package.json Generator
100% LocalScaffold a standard package.json file for Node.js projects.
Basic Information
Configuration
Prevents accidental publishing
Scripts
Privacy note
This tool runs entirely in your browser. Your input is never uploaded, logged, or sent to AllDevToolsHub or anyone else, and it keeps working offline once the page has loaded.
How to Use Package.json Generator
Fill in Package Details
Enter name, version, description, entry point, author, and license.
Add Dependencies
Search and add npm packages with version ranges.
Generate
Copy the complete package.json for your project.
Package.json Generator: the essentials
The Package.json Generator scaffolds a valid Node.js project manifest, name, version, description, author, license, entry points, scripts, type (CJS/ESM), engines, repository link, without running `npm init` or fighting the CLI wizard. Useful for greenfield projects, teaching, or when you just want to skip the questions and edit a clean starting file.
Key points
- Processes configuration and code locally, your project data never leaves your browser.
- Validates against common standards and best practices for the domain.
- Works offline once loaded, no active internet connection required for processing.
Learn More
Configuration Mastery: Taming the YAML vs. JSON vs. TOML War
We Benchmarked 6 JavaScript JSON Parsing Approaches: What Actually Wins in Practice
A realistic comparison of JSON.parse, streaming parsers, bigint-safe parsers, and WASM-based JSON libraries for normalized performance and memory trade-offs.
JSON Schema Validation: Stop Trusting API Responses Blindly
What is Package.json Generator?
Frequently Asked Questions
Technical Deep Dive
Package.json Generator
Quickly build a valid `package.json` file. Define your project name, version, author, license, main entry point, and setup common scripts like start, build, and test. Easily export the raw JSON to initialize your new NPM project without the CLI wizard.
Built for Devs
Designed by people who use these tools in production every day.
Smart Defaults
Reasonable assumptions out of the box, every assumption overridable when you need it.
Workflow-Friendly
Pairs with your IDE, CI, and code review, output drops into commits and PRs cleanly.
Package.json: The Manifest Every Node Project Reads
Every Node.js project starts with package.json. It declares the project's name, version, dependencies, scripts, and dozens of optional fields that tools across the ecosystem consume. Get it right and your project integrates cleanly with npm/yarn/pnpm/bun, IDE tooling, CI/CD, bundlers, and consumers of your published code. Get it wrong and you'll get cryptic errors at install time, broken imports at runtime, and angry GitHub issues from users who can't figure out which entry point to import.
This generator scaffolds a clean starting point. After that, you'll likely add more fields as the project grows.
The Required and Near-Required Fields
name. Lowercase, URL-safe (a-z 0-9 - _ . / @). Scoped packages use @scope/name format. Avoid trademarked names. Avoid names too close to popular packages (typosquats look like attacks). Max 214 characters.
version. Semver: MAJOR.MINOR.PATCH (optionally plus pre-release like 1.0.0-beta.1). Start at 0.1.0 for pre-1.0 packages (some prefer 0.0.1); bump to 1.0.0 when you commit to a stable API. Every published version must be unique, npm forbids overwriting.
description. One sentence. Shown in npm search results, on the package's npmjs.com page, and in IDE tooltips. The most-read text in your package.
main (legacy) or exports (modern). What gets imported when consumers do require('your-pkg') or import 'your-pkg'.
license. SPDX identifier: MIT, Apache-2.0, BSD-3-Clause, etc. Use UNLICENSED for proprietary (npm interprets this specially to forbid publishing).
The Recommended Fields
author. Person or org. Format: "Name <email> (url)" or an object { name, email, url }.
repository. Where the source lives. { "type": "git", "url": "https://github.com/user/repo.git" }. npm uses this for the "view source" link on the package page; GitHub uses it to detect packages associated with the repo.
keywords. Array of strings for search discoverability on npm. Pick 5-10 relevant tags. ["react", "hook", "auth"].
homepage. Optional URL to the project's docs/landing page.
bugs. Where users should file issues. { "url": "https://github.com/user/repo/issues" }.
engines. Supported runtime versions. { "node": ">=18.0.0" }.
The exports Field (Modern Entry Points)
exports is the modern way to declare entry points. Supports conditional exports for different consumers:
This says:
- Importing
your-pkgresolves based on consumer's environment (ESM vs CJS) and gets the right type definitions. - Importing
your-pkg/utilsworks as a subpath. - The package.json itself is exported (some tools need to read it).
- Anything NOT listed in
exportsis not importable,exportseffectively turns on strict encapsulation.
Strict encapsulation is a major change from the pre-exports era when consumers could reach into your package's internals. With exports, you control your public API.
Scripts: The Project's Verbs
Scripts are npm-runnable commands. npm run <name> executes them.
Convention-driven scripts get special treatment:
start:npm startworks withoutrun.test:npm testworks withoutrun.prepublishOnly: runs beforenpm publish.postinstall: runs after dependencies install (use sparingly, security-sensitive).pre<script>/post<script>: lifecycle hooks before/after any other script.
Anti-patterns to avoid:
postinstallscripts that compile native code. Slow installs, fragile across platforms.- Scripts that depend on globally-installed CLIs. Use
devDependenciesandnpxinstead. - Scripts that call other scripts via
npm run. Adds overhead; use direct command composition. - Scripts that depend on bash features. Windows users will hate you. Use
cross-envfor env vars,rimraffor delete,mkdirpfor mkdir.
Dependency Fields
dependencies, runtime deps. Installed when consumers install your package.devDependencies, build-time deps (TypeScript, test framework, bundler). NOT installed for consumers.peerDependencies, deps your consumer must provide. Classic example: a React plugin depends on React but doesn't bundle it; consumers bring their own. npm 7+ auto-installs peers; older versions warn.optionalDependencies, non-fatal deps. Install failures don't abort the install. Used for platform-specific natives.bundledDependencies, deps to include in the published tarball directly. Almost never needed in modern packages.
Version ranges (the right side of "react": "^18.0.0"):
^1.2.3, compatible with 1.x.x where x.x >= 2.3 (caret).~1.2.3, compatible with 1.2.x where x >= 3 (tilde).1.2.3, exact.>=1.2.3, anything higher.*, any.
For libraries: caret on peers (you're flexible). For applications: exact via lockfile (you control upgrades).
Files: What Gets Published
files is an allowlist of paths to include when publishing. Without it, npm includes everything in the directory (minus a default block-list: .git, node_modules, etc.). With it, you publish only what consumers need:
This excludes source TypeScript, test files, configs, and other build artifacts. Smaller published tarball, less surface for consumers to depend on internals.
Always set files. Or use .npmignore (works like .gitignore but for npm). Or rely on files-equivalent fields in newer package configs. Just don't ship your whole repo.
Common Mistakes
"version": "1.0.0"on day one. This commits you to semver from the start, meaning every API change is a major bump. Use0.1.0until the API is stable."main"but no"exports"and no"types". Consumers using TypeScript get no types; tooling falls back toany."type": "module"without configuring tests, build, scripts to handle ESM. Surprises everywhere.- Including all dev deps in
dependencies. Bloats every consumer's install. - No
"license". npm treats missing license as"ISC"by default, but this is often wrong. Be explicit. "private": trueforgotten on internal repos. npm publishes anyway and your code is now public. Always set"private": trueon non-publishable repos.
Privacy
JSON construction is pure string templating in your browser. The output is the only thing leaving via copy-paste, your inputs (project name, author info) stay in the tab. Open DevTools Network during use: zero outbound requests.