

Things You Probably Didn’t Realize npm Could Do - Raphael
http://blog.izs.me/post/1675072029/10-cool-things-you-probably-didnt-realize-npm-could-do

======
aaronblohowiak
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.

=)

------
jacobian
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?

~~~
felixge
No, in fact this style is a little unusal for isaac. Maybe there was beer
involved ; )

------
russell_h
My favorite thing about npm is its 'utils' code:

<https://github.com/isaacs/npm/tree/master/lib/utils/>

I use code from there at least as often as I use actual modules.

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

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

~~~
FooBarWidget
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
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.

~~~
FooBarWidget
> 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.

Yes that's now RPM/DPKG did it so far, but it's nowhere near as flexible as
proper built-in support for multiple versions. What if your app/library
depends on _exactly_ version 1.2.3 of libfoobar? What if another app/library
depends on all versions >= 1.2.4 and < 1.3.0? You can easily specify that with
RubyGems but it's hard to automatically support this in DPKG/RPM. It forces
the DPKG/RPM packager to either impose arbitrary restrictions on what versions
are packaged (and thus restricting which apps are installable) or to work
around it in a stupid way by creating multiple packages, libfoobar1-2-3,
libfoobar-1-2-5, libfoobar-2-0-0. If libfoobar 1.2.6 is released the packager
has to _manually_ rename libfoobar-1-2-5 to libfoobar-1-2-6 and _manually_
rename the dependency names for packages that depended in foobar >= 1.2.4 && <
1.3.0.

This becomes messy and tiresome very quickly. Aren't computers supposed to
help humans?

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

I don't see how sysadmins would reject proper support for multiple versions.
They aren't losing any control over their system or any clarity.

> How useful would it be to auto-detect random crap that's been smuggled onto
> one particular production box behind everyone's backs?

 _Very_ useful because if those "random crap" exist then that means the
sysadmin has _knowingly installed them_ and wants to use them for a reason.
You're basically saying "no user, this is what you want but I'm not going to
allow it". I can't count the number of times where the user wants to upgrade
libxyz to version 2.3.5, but the OS only packages 2.3.4, so the user resorts
to installing from source only to find out that RPM/DPKG dependenceis don't
like that. The user usually ends up uninstalling all those RPM/DPKG packages
and ends up installing those things from source as well.

~~~
prodigal_erik
Gems only works because it's not only a package manager but also a monkey-
patch _for the Ruby interpreter_ which decides on the fly which files it
should actually load. Nobody's going to be able to do that for every language
runtime which has ever existed, so when someone screws up and releases an
incompatible change, you have to give the new version's filesystem contents a
different name, so dependencies have some way to specify which one they need.
At that point it's clearer to rename the package as well.

I wouldn't expect any system to be able to make correct dependency checks (is
this upgrade or uninstall safe?) for discovered files without being told what
the dependencies are. If you have actual sysadmins (not devs who had root by
mistake and misused it) who are smuggling files on a production box that
aren't owned by a package (even one they created themselves), I hope they'll
still be around to suffer the hell they're creating.

~~~
FooBarWidget
You don't have to do that for every language. Just support multiple versions
in DPKG/RPM so that the languages who do support RubyGems-style loading _can_
have multiple versions. Right now converting gems to DPKG/RPM is all manual
work with no good way to automate it. DebGem tries to work around it by making
a DEB that includes all existing versions but it's far from optimal.

> I wouldn't expect any system to be able to make correct dependency checks
> (is this upgrade or uninstall safe?) for discovered files without being told
> what the dependencies are.

So... tell it what the dependencies are?

Autoconf configure scripts can check for arbitrary things. It's just package
managers that insist on only listening to their own databases.

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

------
cloudhead
Hands down the best 'language' package manager.

