What is the exports field for?

The exports field defines the public entry points of a package and, when present, hides every other internal file from importers. It supports conditional resolution so you can ship separate ESM and CommonJS builds and map subpaths like ./utils to specific files.

What does type module do?

Setting type to module makes every .js file in the package be treated as an ES module, so import and export work without a build step. Files that must stay CommonJS should use the .cjs extension; with type commonjs (the default) the reverse applies and ESM files use .mjs.

Difference between dependencies and devDependencies?

dependencies are installed for anyone who installs your package and are required at runtime. devDependencies are only installed for local development and CI and are skipped when your package is installed as a dependency of another project.

What is the files field?

The files field is an allowlist of what gets included in the published tarball. If omitted, npm publishes everything except items in .npmignore or .gitignore. package.json, README, LICENSE, and the main entry are always included regardless.

What does engines specify?

engines declares which Node.js and npm versions your package supports, using semver ranges. By default it is advisory and only warns, but with engine-strict enabled or in some CI setups an out-of-range engine becomes a hard install error.

package.json Fields Reference

Email me this result

Get this tool's output sent to your inbox, plus one useful tool a week. No spam, unsubscribe any time.

package.json is the manifest npm, bundlers, and Node read to understand your package. A single misplaced field can break imports for every consumer or silently publish your entire working tree. This is a searchable reference of the fields you actually touch, with what each one does and where it bites.

How it works

Each field has a defined value type (string, object, array, or boolean) and is read by a specific tool: npm for install and publish behavior, Node for module resolution, and bundlers for entry-point selection. The reference groups fields by purpose:

Identity — name, version, private, license.
Entry points — main, module, types, exports, bin, type.
Dependencies — dependencies, devDependencies, peerDependencies, optionalDependencies.
Publishing — files, publishConfig, engines, os, cpu.
Tooling — scripts, workspaces.

Tips and gotchas

The modern resolution order is exports first (if present, it overrides main), then main for legacy. Always ship a types or typesVersions mapping so TypeScript consumers get types. Remember that an exports map encapsulates the package — anything not listed becomes unreachable, which catches teams that relied on deep imports. For dual ESM/CJS packages, pair type with conditional exports so the right file loads under import versus require.