DevDose: The Real Role of package.json in Your Frontend Project

Day Twelve of Devdose

Introduction:

I was reviewing a flaky build issue for a new team and noticed something off in their setup. It wasn’t the code, tests, or CI, it was a misplaced dependency in package.json.

Real-World Issue:

The project depended on a library only used in the build process, but it was declared as a regular dependency rather than a devDependency. On a clean install, the library triggered a version mismatch on production servers where it wasn’t needed at all. We lost half a day debugging an issue that didn’t belong in runtime.

Concept:

"dependencies": {
  "zone.js": "^0.13.0"
},
"devDependencies": {
  "@angular-devkit/build-angular": "^17.0.0"
}

Knowing where a package belongs matters. Dependencies ship with your production bundle. Dev dependencies do not.

Insight:

Treat package.json like a contract. It declares what your project needs to run, build, and test. Misplacing packages pollutes production environments and slows teams down.

I now review this file line by line when joining a new repo. It’s one of the quickest ways to understand a team’s discipline.

Conclusion:

Every engineer should know how package.json works, not just what it is. It’s more than a config file; it’s your app’s first handshake with the ecosystem.