📦 Dependencies vs DevDependencies: Choose Wisely

package.json has two big buckets: dependencies and devDependencies. Looks minor, yet the choice decides whether production builds succeed, bundles stay lean, and newcomers install the project without surprises.

Quick rule of thumb

Package runs with the app in the browser or on the server → put it in dependencies.
Package is needed only during development or tests → park it in devDependencies.

Unsure? Ask: “Will production crash without this library?” If yes, it belongs to dependencies.

Common cases

UI libraries, routers, HTTP clients. Run in runtime → dependencies.
Bundlers, transpilers, linters. Build-time only → devDependencies.
Testing tools (Jest, Testing Library). Used locally or in CI → devDependencies.
Storybook or mock servers. Help during development → devDependencies.
Runtime SDKs (Sentry, Stripe). Loaded in production → dependencies.
TypeScript typings (@types/*). Needed before build, never shipped → devDependencies.
CSS/UI frameworks. If styles reach the user, add them to dependencies.
CLI helpers (rimraf, cross-env). Only for scripts → devDependencies.

What goes wrong when you mix them up

🧨 Runtime tool in devDependencies. npm install --production skips it, app crashes on deploy.
🐢 Dev tool in dependencies. Bundle gets heavier, install slows down, CI pulls useless megabytes.
🧾 Confusing project map. New engineers struggle to see which packages are critical.

Handy habits

🔍 Scan scripts. If a package appears only in scripts or lint-staged, it almost always belongs to devDependencies.
🧪 Run a prod install. npm ci --only=production tells you whether production has everything it needs.
📝 Keep a short cheat sheet. Note project-specific rules in the README.
🔄 Review regularly. Once a quarter skim package.json and drop unused packages.

Takeaway

Putting packages in the right bucket saves time, space, and nerves. Stick to the simple rule “runtime in dependencies, tooling in devDependencies”, keep the list tidy, and your project will stay healthy. 💪