npm 3 is in beta, and the biggest change is how it handles dependencies. Instead of deeply nested trees, npm 3 tries to flatten them. This seemingly small change has significant implications for how we use npm, especially for frontend code.
The Nested Dependency Problem
npm's current model (npm 2) creates nested dependency trees:
node_modules/
package-a/
node_modules/
[email protected]/
package-b/
node_modules/
[email protected]/This works for Node.js—each package gets exactly what it needs. But for frontend code bundled with browserify or webpack, this creates problems:
- Multiple copies of the same library
- Larger bundle sizes
- Deduplication becomes complex
- Singleton dependencies (React, Angular) break with multiple versions
Bower solved this by forcing flat dependencies. But maintaining two package managers is painful. npm 3 brings flat dependencies to npm.
How npm 3 Works
npm 3 still allows multiple versions but tries to install them flat:
node_modules/
package-a/
package-b/
[email protected]/ <- First version installed wins
package-c/
node_modules/
[email protected]/ <- Conflicting version nestedThe first package installed gets its dependencies at the top level. Conflicting versions get nested only when necessary. This maintains compatibility while reducing duplication.
The flattening is deterministic—install order matters, but package-lock.json will ensure consistency across machines.
The Breaking Changes
Flatter dependencies change assumptions code might have:
Require paths might break. Code doing require('../../node_modules/something') will break. But this was always fragile.
Peer dependencies work differently. npm 3 doesn't auto-install peer dependencies. You need to install them explicitly. This is more correct but requires adjustment.
Install is slower initially. Computing the optimal flat tree takes time. But subsequent installs with package-lock are faster.
These are acceptable trade-offs for better frontend support.
The Bower Question
With npm 3, is Bower still needed? The case for Bower was flat dependencies. npm 3 provides that.
But Bower has advantages:
- Truly flat (npm 3 nests when necessary)
- Designed for frontend (no Node assumptions)
- Established ecosystem for frontend libraries
npm's advantages:
- One package manager for everything
- Larger ecosystem
- Better tooling integration (package-lock, scripts)
My prediction: npm 3 accelerates npm's takeover of frontend package management. Bower won't disappear immediately, but momentum shifts further toward npm.
Performance Implications
Flatter trees mean:
- Less disk space (fewer duplicate dependencies)
- Faster require() in Node (fewer directory traversals)
- Better frontend bundling (less deduplication needed)
- Slower initial installs (computing optimal tree)
The trade-offs favor flatten for most use cases.
The Determinism Challenge
npm 2's nested trees were deterministic—same package.json always produced the same tree. npm 3's flattening depends on install order, which could vary.
package-lock.json solves this by recording the exact tree. But this requires npm 5+ and adoption takes time. Until then, reproducible installs need care.
Migration Path
npm 3 is backward compatible—most code works unchanged. But to take advantage:
- Remove unnecessary flat dependencies from Bower
- Test with npm 3 beta
- Fix any require path assumptions
- Explicitly install peer dependencies
- Update CI to use npm 3
The migration is manageable, not disruptive.
Looking Forward
npm 3 positions npm as the universal JavaScript package manager. Frontend, backend, build tools, CLI utilities—all use npm.
This unification simplifies workflows even if it's not perfect. Having one tool that handles 90% of cases beats having two tools that handle 100% of their specific cases.
Bower's future is uncertain. It works well, but network effects favor npm. Maintaining a separate ecosystem becomes harder as npm improves.
Resources:
- npm 3 Beta – Release notes
- npm 3 Dependency Resolution – How flattening works
- Bower – Still relevant for now
