Package JSON Generator

What Is package.json

Every Node.js project has a package.json at its root. It is the manifest npm reads to learn the project's name, version, entry point, dependencies, and scripts. When you run npm install, npm resolves the dependencies listed there. When someone publishes or clones the project, this file tells tooling how to build it and which modules to load. A malformed name or version can stop an install or a publish before it starts, which is why generating the file from a form with built-in validation is faster and safer than hand-editing JSON.

This generator runs entirely in your browser. It validates the package name against npm's naming rules, checks the version against the semantic versioning specification, parses your scripts and dependency lists, and warns about malformed lines as you type. Nothing is uploaded, so you can safely build a manifest for a private or proprietary package.

How to Use It

1. Enter the package name. npm names must be lowercase, URL safe, and may be scoped, for example @acme/utils.
2. Set the version using semantic versioning, such as 1.0.0.
3. Fill in the description, entry point, module type, author, keywords, and repository URL. Empty optional fields are omitted from the output.
4. Pick a license from the SPDX list, or choose UNLICENSED for private code.
5. Add scripts as name=command pairs, one per line, and dependencies as name@version lines.
6. Copy the generated JSON or download it as a package.json file. Any validation issues appear above the output.

Required and Optional Fields

Only two fields are strictly required: name and version. Everything else is optional, but a few optional fields carry real weight. The description appears in npm search results. The main field tells Node which file to load on require(), while type decides whether .js files are treated as CommonJS or ES modules. The license field matters to companies auditing dependencies. The private flag prevents accidental publishing to the public registry, which is the right choice for applications that are never meant to be packages.

Dependencies vs Dev Dependencies

Packages listed in dependencies are installed in every environment and ship with your package when it is used as a dependency itself. Dev dependencies are installed only during development and for consumers who clone the repository, not when your package is installed from the registry. Put build tools, test runners, formatters, and type definitions in dev dependencies. A third category, peer dependencies, is not part of this generator because it is used only by plugins and frameworks that expect the host project to provide a compatible version, such as React component libraries.

Version Ranges Explained

A dependency version can be an exact value like 1.2.3, or a range. The caret range ^1.2.3 accepts any version from 1.2.3 up to but not including 2.0.0, so bug fixes and features arrive automatically while breaking changes stay blocked. The tilde range ~1.2.3 accepts only patch updates, up to but not including 1.3.0. An asterisk accepts anything, which is convenient for throwaway scripts and dangerous for production. A lock file records the exact resolved versions for reproducible installs, so ranges describe intent while the lock file guarantees the outcome.

Scripts Worth Defining

Scripts are shortcuts run with npm run. A solid baseline is dev for the local development server, build for the production bundle, test for the test suite, and lint for static checks. Because npm test, npm start, and npm stop are special, you can also run those three directly without the run keyword. CI systems and deployment platforms look for these conventional names, so matching them pays off. Remember that scripts defined in a dependency cannot affect the installing project: npm deliberately blocks lifecycle scripts from packages that are not listed as trusted.

Common Mistakes to Avoid

• Uppercase or spaces in the name. New packages must be lowercase and URL safe.
• A version that is not major.minor.patch. Publishing rejects anything else.
• Build tooling in dependencies, which bloats installs for every consumer.
• Forgetting private: true on application repositories, which risks an accidental publish.
• Duplicating a package in both dependency lists, where npm silently prefers one.

Related tools: generate a matching .gitignore for your stack, add a license file for the SPDX identifier you chose, create an .env file for local configuration, and validate or pretty print any JSON with the JSON Formatter.