Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm using Composer to manage my PHP dependencies, and would be happy to do the same with my JS dependencies.

I stumbled upon NPM for Node.js, and am wondering if it's supposed to be used as a client-side dependency manager as well.

For example, I might want to manage the client-side library dependencies in my application's /public/vendor/ folder, and install/update these dependencies as I would do with composer install or composer update for PHP.

Is npm for me?

share|improve this question
up vote 4 down vote accepted

Not directly, though some of the packages you install via npm (e.g. will emit client-side Javascript libraries.

There's another tool called Bower which is designed for client-side Libraries. There may be others, but this is the one I've seen mentioned the most. It's used internally by Google's Yeoman tool for the client-side libraries.

share|improve this answer
Great. Thanks for your answer! – Benjamin Feb 19 '13 at 18:07

There is an enthusiastic case made here, which ends with the summary:

All package managers do relatively the same thing. Move files. Pick a package manager on how well it does that. All build tools do relatively the same thing. Transform files. Pick your build tools on how well they do that. If you're not using npm now solely because someone told you it isn't for client side. Slap them and say, "npm all the things."

My own way of looking at it: client and node can very often make use of common code. Therefore one day it will be sensible for client and node projects to occupy the same repository. Whichever repository that is, it will (ideally) gain critical mass and replace all other client and node repositories. And as npm is already so well established, why shouldn't it become that repository?

share|improve this answer
Interesting reading. Thank you. – Benjamin Aug 2 '13 at 20:39

NPM was designed specifically to manage JavaScript packages running under Node.js (server side). Now when there are ~80000 packages in the npm public repository some problems with the original design (e.g. the flat namespace problem) arose and alternative JavaScript package managers appeared.

One that until recently aimed to solve all those JavaScript server/side client/side package dependency problems is the component package manager using GitHub repository and its namespacing.

This article was at the beginning:

There are currently ~2500 packages in the component public repository.

Short comparison with other JavaScript package managers is available here:

share|improve this answer

There's a recent blog post about this from NPM:

“npm is only for server-side JavaScript!”

Also not true. Your package can contain anything, whether it’s ES6, client-side JS, or even HTML and CSS. These are things that naturally turn up alongside JavaScript, so put them in there.


If it’s JavaScript-related, host it in npm. Once they are available, use ecosystems to create “mini-registries” within the global one, complete with custom search indexing and display characteristics.

So, yes. It's very much ok to put client-side JavaScript stuff in NPM, and they will improve the support for that.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.