Is npm designed to be used to manage client-side dependencies as well?

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?

Solution 1:

Not directly, though some of the packages you install via npm (e.g. socket.io) 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.

Solution 2:

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?

Solution 3:

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: http://tjholowaychuk.tumblr.com/post/27984551477/components

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

Short comparison with other JavaScript package managers is available here: https://github.com/component/guide/blob/master/component/vs.md

Solution 4:

There's a recent blog post about this from NPM: http://blog.npmjs.org/post/101775448305/npm-and-front-end-packaging

“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.