node-pre-gyp brings in over 100 new dependencies.

[lilyissillyyy]

Issue or Feature

I know this was mentioned partially in #1108, but I feel this should be brought up directly into it's own issue.

Before node-pre-gyp, canvas was a very tiny lib, requiring a mere single dependency. This was actually a large draw to the project for me. Now however, as you can see by this lovely visualization, it is over 100. That's a massive increase in the amount of packages we need to bring in to use canvas all for a prebuild that may not even function as expected or be wanted by the developer. I would be fine with this if it were a small package providing the same functionality, but over 100 deps for a prebuild that only ever runs a single time is a little ridiculous. I'm aware replacing request would fix a lot (mapbox/node-pre-gyp#340), but this would still be a huge dependency even without it, and I'm confused as to why this is necessary at all. Please reconsider bringing such a huge dependency into the project, it's really not good for anyone to be subjected to such dependency hell.

Your Environment

• Version of node-canvas (e.g. 1.4.0): 2.0.0-alpha.11
• Environment (e.g. node 4.2.0 on Mac OS X 10.8): node 9.8.0 (though it applies to all OSes)

[piranna]

I agree, prebuild and prebuild-install has by far a lot less dependencies since they rely in the node-gyp` package already included with Node.js instead of having it as a direct dependency (and so, forcing it to download and install it again).

[spatialillusions]

FYI. At the moment the download of prebuilt libraries using node-pre-gyp is broken because of mapbox/node-pre-gyp#359
It looks like it is patched and will be fixed in the next release of node-pre-gyp.

[chearon]

FYI. At the moment the download of prebuilt libraries using node-pre-gyp is broken because of mapbox/node-pre-gyp#359

I'm really surprised that issue is weeks old and there aren't more people affected. node-pre-gyp is currently broken for anyone hosting releases on GitHub! It could be that it's slowly affect more people as their versions of node-pre-gyp upgrade themselves.

More reasons to find something better to replace node-pre-gyp...

[spatialillusions]

What might cause added problems is that for people that has updated to npm 5.8.0, pre-gyp is no longer installed by default.
mapbox/node-pre-gyp#362
Looks like it will be fixed, in npm, but will cause problems for people running 5.8.0.

[piranna]

prebuild-install do't have these problems...

[zbjornson]

Version 0.9.0 of node-pre-gyp switched from request (44 dependencies) to needle (5 dependencies), which brings the total number of "nodes" reported by anvaka for node-pre-gyp to 70. An improvement but still sort of a lot...

[chearon]

node-pre-gyp also doesn't work correctly with yarn, I forget if we had a discussion about that already but yarn install canvas@next didn't fallback to build for me yesterday, so we should take another look at prebuild-install or something custom

[LinusU]

I was reading a long blog post about a new project that basically shipped the binaries as part of the package to npm. I thought that they had some really good reasons on why to do that, and they had talked to someone at Npm which thought it was a good idea as well.

I just can't remember the name 😆

edit: here we go: https://www.nearform.com/blog/the-future-of-native-modules-in-node-js/

[zbjornson]

I didn't know that yarn doesn't fall back to build, but there's this yarn issue which prevents using --build-from-source: yarnpkg/yarn#5247

I think I sent that same article to @chearon ... Might have been this one? https://www.nearform.com/blog/the-future-of-native-modules-in-node-js/

With prebuildify instead of downloading a prebuild for your platform at installation time, we simply bundle all prebuilds for all platforms inside a ./prebuilds folder in the node_modules before it is published to npm.

[chearon]

yarnpkg/yarn#5247

I didn't investigate deeply but I assumed it was the same issue as that. --fallback-to-build wasn't passed to node-pre-gyp