I would completely understand if this _was_ a server side shopping cart, but it's not. It's a client side shopping cart which you can use on any architecture - you just have to give it data, and then check the data at payment using whatever server side language you want. It's not any different to a Spine or Backbone based project.
Just because it's JavaScript doesn't mean it should be in npm, similar to just because a project is written in ruby doesn't mean it should be in rubygems. A lot of the time, there's no reason for a ruby project to be bundled as a gem - it just ends up polluting an already crowded package management ecosystem. I wasn't sure if there was something I might have missed about npm. To me, it seems like it would be something that would be better managed with Bower ( http://twitter.github.com/bower/ ) given you don't (and shouldn't!) need npm in order to use it.
I read your original reply to hayksaakian as an enquire as to why hayksaakian would assume the js to be related to node since the js is client side.
In that context, my reply means that since hayksaakian started with the assumption that it was server side, it's only logical that he would conclude the js to be a node module since server-side javascript's most popular implementation is node.
Of course, looking back I see that I may have misread hayksaakian's reply.
Just because it's JavaScript doesn't mean it should be in npm, similar to just because a project is written in ruby doesn't mean it should be in rubygems. A lot of the time, there's no reason for a ruby project to be bundled as a gem - it just ends up polluting an already crowded package management ecosystem. I wasn't sure if there was something I might have missed about npm. To me, it seems like it would be something that would be better managed with Bower ( http://twitter.github.com/bower/ ) given you don't (and shouldn't!) need npm in order to use it.