5 ms·

Things You Probably Didn’t Realize npm Could Do

54 points by Raphael 16y ago

chapel 16y ago
I really enjoy npm and think it is a great way to handle node.js modules.
jacobian 16y ago
As a Node noob, I have to ask: is the tone of this article indicative of the general attitude and style of the Node community?
- deleted 16y ago
  [deleted]
- felixge 16y ago
  No, in fact this style is a little unusal for isaac. Maybe there was beer involved ; )
- Rauchg 16y ago
  If you mean people being passionate about their software, re-thinking the conventions and sharing their ideas, then yes.
aaronblohowiak 16y ago
The automatic dependency management that lets you have conflicting version dependencies is one of the big wins with commonjs and npm makes it so easy that it "just works". npm is great, and isaac is usually very responsive on irc. that being said, there's still something a little irksome about encouraging people to curl a .sh and pipe it to bash. =)
russell_h 16y ago
My favorite thing about npm is its 'utils' code: https://github.com/isaacs/npm/tree/master/lib/utils/ https://github.com/isaacs/npm/tree/master/lib/utils/ I use code from there at least as often as I use actual modules.
cloudhead 16y ago
Hands down the best 'language' package manager.
prodigal_erik 16y ago
What is so seductive about reinventing package management but not finishing the job? Is this really that different than any of the other single-language ghettos which can't interop at all with the only package manager I care about, namely the one already on each of our systems that knows everything that's installed, and that our sysadmins have learned the ins and outs of? If I can't "yum install" a Node app and bring in its missing dependencies, I view any packaging the authors did as a waste of time, because I'm going to have to redo it anyway before it goes on our hardware.
- zokier 16y ago
  I agree that the trend of single-language package managers is unwelcome, but that doesn't mean that package management as a field doesn't need to innovate. And building package manager that can co-exist with systems own package manager is a lot easier in many ways than building a new distro at the same time.
- FooBarWidget 16y ago
  To "finish the job" one has to patch the native package managers themselves which is a huge undertaking. Neither DPKG nor RPM support installing multiple versions of the same package. Furthermore, why should it be npm/RuyGems/CPAN/easy_installs/pip's responsibility to "finish the job"? Why can't DPKG and RPM just support multiple versions as well as the ability to recognize files outside their native database? Right now DPKG and RPM don't recognized software installed from source tarballs (./configure && make install).
  - prodigal_erik 16y ago
    Linear versioning has the baked-in promise that version N is no longer needed because version N+1 is substitutable for it. If that's not true, if apps legitimately depend on specific revisions of the library code (because its authors are not maintaining backwards compatibility), those library builds need different names so they can coexist in the filesystem and dependent apps can name the one they need. There's no reason to treat them as versions of the same package, because switching between them is effectively migrating from one dependency to another (which happens to have many authors in common). > why should it be npm/RuyGems/CPAN/easy_installs/pip's responsibility Because they each have far less work to do than the growing number of spur-of-the-moment integration targets that rpm and dpkg would face. It deters them from requiring features which rpm and dpkg don't have, and which they aren't prepared to implement in a way that every sysadmin everywhere is willing to rely on. And it's they who are creating the problem. > recognize files outside their native database How useful would it be to auto-detect random crap that's been smuggled onto one particular production box behind everyone's backs? You wouldn't know how to uninstall it cleanly, nor what its dependencies currently are (so you could ever safely uninstall anything without potentially breaking it), nor whether it'll be okay to clobber it with a legitimate version from a repository (or what might break if yum let you do it). I'm not that familiar with dpkg, but those are awfully fragile results just to avoid writing an rpmbuild .spec that definitely states these facts and then runs ./configure && make install. -- If I seem like I have a grudge, it's because we spent months digging ourselves out of the hell of "this code is just somehow there on a few of our machines, but we don't know which version it was for which files, how they got there, or how to cleanly deploy a new server that actually works." Unfortunately the pain wasn't borne by the slobs whose negligence got us there over years. That's a drawback to startups—between failures and turnover, too many authors aren't required to work with reckless implementations long enough to learn how bad some ideas really are.
zokier 16y ago
I guess there is no way to use the multiple version management with other languages?

54 points by Raphael 16y ago

I really enjoy npm and think it is a great way to handle node.js modules.

As a Node noob, I have to ask: is the tone of this article indicative of the general attitude and style of the Node community?

deleted 16y ago
[deleted]
felixge 16y ago
No, in fact this style is a little unusal for isaac. Maybe there was beer involved ; )
Rauchg 16y ago
If you mean people being passionate about their software, re-thinking the conventions and sharing their ideas, then yes.

aaronblohowiak 16y ago

The automatic dependency management that lets you have conflicting version dependencies is one of the big wins with commonjs and npm makes it so easy that it "just works". npm is great, and isaac is usually very responsive on irc. that being said, there's still something a little irksome about encouraging people to curl a .sh and pipe it to bash. =)

russell_h 16y ago

My favorite thing about npm is its 'utils' code: https://github.com/isaacs/npm/tree/master/lib/utils/ https://github.com/isaacs/npm/tree/master/lib/utils/ I use code from there at least as often as I use actual modules.

cloudhead 16y ago

Hands down the best 'language' package manager.

prodigal_erik 16y ago

What is so seductive about reinventing package management but not finishing the job? Is this really that different than any of the other single-language ghettos which can't interop at all with the only package manager I care about, namely the one already on each of our systems that knows everything that's installed, and that our sysadmins have learned the ins and outs of? If I can't "yum install" a Node app and bring in its missing dependencies, I view any packaging the authors did as a waste of time, because I'm going to have to redo it anyway before it goes on our hardware.

zokier 16y ago
I agree that the trend of single-language package managers is unwelcome, but that doesn't mean that package management as a field doesn't need to innovate. And building package manager that can co-exist with systems own package manager is a lot easier in many ways than building a new distro at the same time.
FooBarWidget 16y ago
To "finish the job" one has to patch the native package managers themselves which is a huge undertaking. Neither DPKG nor RPM support installing multiple versions of the same package. Furthermore, why should it be npm/RuyGems/CPAN/easy_installs/pip's responsibility to "finish the job"? Why can't DPKG and RPM just support multiple versions as well as the ability to recognize files outside their native database? Right now DPKG and RPM don't recognized software installed from source tarballs (./configure && make install).
- prodigal_erik 16y ago
  Linear versioning has the baked-in promise that version N is no longer needed because version N+1 is substitutable for it. If that's not true, if apps legitimately depend on specific revisions of the library code (because its authors are not maintaining backwards compatibility), those library builds need different names so they can coexist in the filesystem and dependent apps can name the one they need. There's no reason to treat them as versions of the same package, because switching between them is effectively migrating from one dependency to another (which happens to have many authors in common). > why should it be npm/RuyGems/CPAN/easy_installs/pip's responsibility Because they each have far less work to do than the growing number of spur-of-the-moment integration targets that rpm and dpkg would face. It deters them from requiring features which rpm and dpkg don't have, and which they aren't prepared to implement in a way that every sysadmin everywhere is willing to rely on. And it's they who are creating the problem. > recognize files outside their native database How useful would it be to auto-detect random crap that's been smuggled onto one particular production box behind everyone's backs? You wouldn't know how to uninstall it cleanly, nor what its dependencies currently are (so you could ever safely uninstall anything without potentially breaking it), nor whether it'll be okay to clobber it with a legitimate version from a repository (or what might break if yum let you do it). I'm not that familiar with dpkg, but those are awfully fragile results just to avoid writing an rpmbuild .spec that definitely states these facts and then runs ./configure && make install. -- If I seem like I have a grudge, it's because we spent months digging ourselves out of the hell of "this code is just somehow there on a few of our machines, but we don't know which version it was for which files, how they got there, or how to cleanly deploy a new server that actually works." Unfortunately the pain wasn't borne by the slobs whose negligence got us there over years. That's a drawback to startups—between failures and turnover, too many authors aren't required to work with reckless implementations long enough to learn how bad some ideas really are.

zokier 16y ago

I guess there is no way to use the multiple version management with other languages?