package.json: the 6 fields you actually need

Most package.json files are over-configured

Ignore the 40 fields tutorials list. The 6 that matter for a normal app:

{
  "name": "my-app",
  "version": "0.1.0",
  "type": "module",
  "scripts": {
    "dev": "vite",
    "build": "vite build",
    "test": "vitest"
  },
  "dependencies": {
    "react": "^18.3.1"
  },
  "devDependencies": {
    "vite": "^5.4.0",
    "vitest": "^2.0.0"
  }
}

• `name` — what npm calls your package. Required even for private apps.
• `version` — semver MAJOR.MINOR.PATCH.
• `type": "module"` — makes Node treat .js files as ES modules. Almost always what you want in 2026.
• `scripts` — npm run X shortcuts. The three above (dev / build / test) are the universal ones.
• `dependencies` — runtime deps. Ship to production.
• `devDependencies` — build / test only. Do NOT ship.

Fields you only need for libraries

exports (controls what's importable from the package), main / module (legacy entrypoints), files (npm publish allowlist). If you're not publishing to npm, you don't need any of these.

Two anti-patterns

1. Putting Vite in `dependencies` — it's a build tool, belongs in dev deps. Same for vitest, eslint, prettier.
2. Locking versions to exact `1.2.3` — use ^1.2.3 so patches land automatically. Pin only when a specific bug forces it; document why.

"I committed package-lock.json — was that right?"

Yes. package-lock.json (or pnpm-lock.yaml / yarn.lock) records exact resolved versions so every install gets identical bytes. Commit it. Don't commit node_modules/.