Bug 1290781

npm itself has around 50 direct js dependencies, which have another dependencies etc, so consequently you have around 100 nodejs-* dependencies. npm also depends on packages like nodejs, node-gyp and v8, which require another packages like C compiler and *-devel packages.

Realistically, this is not going to change. It doesn't make any sense for Fedora to have an NPM that doesn't match upstream behavior.

Still, if we install the binaries from https://nodejs.org/en/download/stable/ we don't need a C compiler and what else.

Why do the fedora installation need all these dependencies when the upstream version does not?

(In reply to Dennis Björklund from comment #3)
> Still, if we install the binaries from
> https://nodejs.org/en/download/stable/ we don't need a C compiler and what
> else.
> 
> Why do the fedora installation need all these dependencies when the upstream
> version does not?

So, the upstream version is basically "cheating". Node's package.json requires that npm includes 'node-gyp', which is a cross-platform tool for building natively-compiled modules. This module is not functional *in any way*, without a compiler on the system, so Fedora's guidelines require that this becomes a strict dependency (so people aren't installing it then immediately filing bugs because it "doesn't work").

npm relies on it because if the user wants to install a native module (or something that depends on a native module somewhere in its dependency chain), it needs to be able to compile it natively on that user's system. Since this is part of a major piece of the npm functionality, we left it in there because (again) we don't want users installing npm, trying to install other modules and hitting what to them will be a bug.

We sometimes refer to this as "the principle of least surprise": what choice can we make so that the user experiences the fewest number of surprises. In this case, we make the assumption that the user expects that when they install 'npm', they will be able to use the npm command for any upstream module (to the best of our ability). This does result in a default case where there are more packages pulled into the installation than some users (such as you, Dennis) are expecting, but the net result is that the package works as expected in hopefully all cases.

Upstream Node.js on the other hand, chose a different path: they choose to bundle a copy of npm with Node.js that behaves differently based on the state of the user's computer. If they have a C/C++ compiler on the system, then npm will be able to install binary packages. If they don't, it will fail in a way that may confuse a non-technical user.

In Fedora, however, we *do* have one other option that we didn't have when npm first landed in the distribution. We now have the ability to specify weak dependencies, not just strict ones. I still think we need to *default* to providing all functionality (thereby maintaining the principle of least surprise), but we *could* modify the node-gyp package such that it only `Recommends: gcc-c++` rather than `Requires: gcc-c++`. The difference here means that one should be able to do `dnf install npm --exclude=gcc-c++` and then you would get the behavior originally requested: an npm on the system that only works for native modules and has none of the compiler chain present.

Does that sound like a reasonable approach?

Shouldn't the weak dependency be from npm to node-gyp? node-gyp is pretty much useless without a compiler but npm is perfectly useful without node-gyp - it only becomes an issue if you want to install a binary modyle.

I wont pretend that I know that much about nodejs and npm but my understanding is that node-gyp is a separate tool that you usually install using npm itself (for the non-fedora users) and that npm work fine without it.

So having node-gyp as a weak dependency from npm sound right to me and in line with the upstream intentions.

How bad is the error message you get from npm if you don't have node-gyp installed and you do something where npm need node-gyp?

I also agree that node-gyp should have a strict dependecy on the compiler since it doesn't work at all without it.

(In reply to Tom Hughes from comment #5)
> Shouldn't the weak dependency be from npm to node-gyp? node-gyp is pretty
> much useless without a compiler but npm is perfectly useful without node-gyp
> - it only becomes an issue if you want to install a binary modyle.

The problem with that is that the node-gyp dependency is handled by package.json and auto-detected. Yes, we can remove and add it as a Recommends: manually, but that will be error-prone if we forget to update the dependency when the requirements change. I suppose it would be more correct, though.

(In reply to Dennis Björklund from comment #6)
> I wont pretend that I know that much about nodejs and npm but my
> understanding is that node-gyp is a separate tool that you usually install
> using npm itself (for the non-fedora users) and that npm work fine without
> it.
> 

You don't install it separately; it's actually present in the binary package as a bundled dependency, it's just shipped non-functional.

> So having node-gyp as a weak dependency from npm sound right to me and in
> line with the upstream intentions.
> 

See above.

> How bad is the error message you get from npm if you don't have node-gyp
> installed and you do something where npm need node-gyp?
> 

That's a good question; I haven't tried it but I suspect that it will essentially look like a compilation error.

> I also agree that node-gyp should have a strict dependecy on the compiler
> since it doesn't work at all without it.

(In reply to Stephen Gallagher from comment #7)
> (In reply to Tom Hughes from comment #5)
> > Shouldn't the weak dependency be from npm to node-gyp? node-gyp is pretty
> > much useless without a compiler but npm is perfectly useful without node-gyp
> > - it only becomes an issue if you want to install a binary modyle.
> 
> The problem with that is that the node-gyp dependency is handled by
> package.json and auto-detected. Yes, we can remove and add it as a
> Recommends: manually, but that will be error-prone if we forget to update
> the dependency when the requirements change. I suppose it would be more
> correct, though.

Another use for my (currently mythical) fixdep --convert-to-opt switch, combined with handling optionalDependencies in the requirement generator ;-)

(In reply to Tom Hughes from comment #8)
> Another use for my (currently mythical) fixdep --convert-to-opt switch,
> combined with handling optionalDependencies in the requirement generator ;-)

Thanks for volunteering to take this one :)

This should be fixed in f24 as we are now using the bundled npm.