G2

Pooja P.

Senior Frontend Engineer

Enterprise (> 1000 emp.)

9/30/2026

"npm: Reliable, Ubiquitous, and Effortless for Onboarding and Integration"

5/5

What do you like best about npm?

After about seven years of front-end work, npm is the one tool that's been in every project I've touched, from AngularJS apps built with Grunt to Angular micro frontends and AI-driven products. What I value most is its reliability and ubiquity. Integration is effortless because every library publishes to it, whether it's Angular, PrimeNG, D3, or Syncfusion, and every build tool and CI pipeline supports it out of the box. Onboarding is just as smooth. It ships with Node, every developer already knows it, and a new teammate can clone a repo, run npm install and npm start, and be productive within minutes. And it's completely free, which makes it an easy standard to adopt across teams without any budget discussion.

I've also watched it mature a lot. Early on, installs were slow and inconsistent across machines, but package-lock.json, npm ci, and performance improvements in later versions made builds genuinely reproducible. Features like workspaces, overrides for patching vulnerable transitive dependencies, and .npmrc configuration for private registries have made it practical for enterprise teams. I've used private registries to share internal component libraries across projects, and npm makes publishing and versioning those packages straightforward with semantic versioning.

Day to day, npm scripts are what I rely on most. They act as a simple, standardized interface for every project, so whether it's npm start, npm test, or npm run build, anyone can pick up a repo and work the same way. I've tried Yarn and pnpm, and they each have their strengths, but npm remains my default because it's stable, well documented, and works everywhere without extra setup. Review collected by and hosted on G2.com.

What do you dislike about npm?

Honestly, there's not much to complain about when it comes to onboarding, integration, or cost. It's free, it works with everything, and every developer already knows it. My frustrations are mostly around dependency management at scale. The node_modules folder gets huge very quickly, and a single package can pull in hundreds of transitive dependencies you never asked for. Peer dependency conflicts are a regular headache, especially during Angular upgrades, and I've lost count of how many times the fix was --legacy-peer-deps just to get an install to succeed, which always feels like hiding a problem rather than solving it.

Security is the other big concern. Since anyone can publish a package, supply chain risks like compromised or typosquatted packages are real, and one bad transitive dependency can affect your whole app. npm audit helps, but it's noisy and often flags vulnerabilities in dev-only tools that don't actually matter, so teams start ignoring it, which defeats the purpose. Package-lock merge conflicts in busy repos are another small but constant annoyance, and compared to pnpm, npm is still slower and less efficient with disk space. None of these are deal breakers, but they're the reasons dependency hygiene takes real discipline on any long-lived project. Review collected by and hosted on G2.com.

What problems is npm solving and how is that benefiting you?

The core problem npm solves is managing dependencies in a consistent, repeatable way. Modern front-end projects rely on dozens of libraries, and without a package manager, keeping track of versions, installing them correctly on every machine, and updating them safely would be chaos. npm handles all of that through package.json and the lock file, so every developer and every CI build gets exactly the same setup. That consistency has saved me from countless "works on my machine" issues over the years.

It also standardizes how projects are run. With npm scripts, every repo I work on has the same entry points for starting, testing, building, and linting, no matter how different the underlying tooling is. That was especially valuable in the micro-frontend project I worked on, where multiple apps ran different Angular versions. Each app managed its own dependencies independently through npm, so we could upgrade one without breaking the others.

There are faster alternatives like pnpm, and Yarn has some strong monorepo features, but npm's biggest advantage is that it's the default. It ships with Node, so every developer already has it, every library's docs start with npm install, and every CI tool supports it out of the box. Even Yarn and pnpm pull packages from the npm registry, which shows how central it is to the whole JavaScript ecosystem. Over the years npm has also closed most of the gaps that made alternatives popular, adding lock files, faster installs, workspaces, and overrides, and being backed by GitHub gives enterprises confidence in its long-term stability. For most teams, switching just isn't worth the retraining and tooling changes.

The biggest benefit for me and my teams has been speed and confidence. New developers are productive on day one, builds are reproducible across environments, and tools like npm audit, npm outdated, and overrides help us keep dependencies secure and up to date. Sharing internal packages through private registries has also cut down on duplicated code across projects. Overall, npm lets us spend our time building features instead of managing setup, and that's a huge return for a tool that costs nothing. Review collected by and hosted on G2.com.