Dependency types: dev, peer, optional

package.json has several dependency fields, each with different install behaviour:

• dependencies: needed at runtime. Installed for your project and for anyone who installs your package.
• devDependencies: needed only to develop, build or test (TypeScript, test runners, linters, bundlers). Installed for your project, never for consumers of a published package. Skip them in production with npm ci --omit=dev.
• peerDependencies: "I plug into a host package the consumer provides." A React component library declares "react": "^18 || ^19" as a peer instead of bundling its own React. Since npm 7, missing peers are installed automatically, and conflicting peer ranges fail with ERESOLVE. Mark optional peers with peerDependenciesMeta.
• optionalDependencies: installed if possible; a failure (e.g. a platform-specific native binary) does not fail the install. Your code must handle their absence.
• bundleDependencies: shipped inside your package tarball.

For bundled frontend apps the distinction is softer, since the bundler decides what ships; many teams still keep build tools in devDependencies for faster CI installs.

--legacy-peer-deps ignores peer dependencies entirely and --force overrides conflicts. Both hide real incompatibilities; prefer fixing versions or using overrides.