Can't install multiple architectures at once.

[cscott]

The old binary installation scheme installed binaries under (for example) lib/binding/Release/node-v11-linux-ia32/node_sqlite3.node. The new scheme omits the architectures and node version number and installs as lib/node_sqlite3.node. This is a severe regression! I can no longer use a shared node_modules directory tree for deployments on multiple versions of node or architectures.

Please restore the ability to install multiple binaries for sqlite3 in the same node_modules tree.

[cscott]

This looks to have been fixed in 942d915 but not released yet?

It would be really nice if this were the default setup for node-pre-gyp, since many node packages suffer from this basic flaw.

[springmeyer]

I can no longer use a shared node_modules directory tree for deployments on multiple versions of node or architectures.

This is exactly what mapbox/node-pre-gyp#18 is about, but it needs work and a good implementation.

This is a severe regression!

Sorry, had no idea anyone was depending on this, or even noticed that I implemented this in the original binary install method (the build.js before I started node-pre-gyp as a separate project).

So, if you need it we should be able to provide. I'm interested to hear more about your use case if you can share. Thanks.

[cscott]

Sure: this is how wikimedia handles node deploys. (The mechanism is in a bit of flux, so everything may change tomorrow, but this is a snapshot.) We have a repo for the software itself, and then a separate repo for the node_modules which we use for deployment. We used to checkout the node_modules repo as a git submodule, but that proved clumsy in practice, so now it's a separate git repo which can be symlinked into the main repo for development. Deploys clone the main repo and the submodule on all the production servers. The continuous integration test server also does this two-step clone, so we are quickly warned if the "production" versions of the node_modules need to be updated (which is done via a commit to the separate node_modules repo, which goes through code review & etc as per our usual process). Individual developers are also encouraged to clone the deployment repo for node_modules, to ensure they are testing exactly what is deployed.

So we've got at least three different environments using the same node_modules -- the production servers, the continuous integration test servers, and developers' local machines. We currently have a mix of node 0.8 and node 0.10 running in production, node 0.8 on the continuous integration test servers, and individual developers are often running node 0.11 to ensure that nothing is broken by the lastest stuff coming down the node pipeline. (We used to have node 0.6 in the mix as well, since that's what Ubuntu's latest LTS has/had). There are several different minor versions of these running as well.

In addition, our production machines are all x64, but developer machines are a mix of x64, i386, and sometimes even arm.

This all works fine with the old packaging strategy for node-sqlite3, since we can easily add new binaries for different architectures, and developers' local architecture binaries don't overwrite the existing files if they need to run something unusual on their local machines. And indeed, I've ported the node-sqlite3 system to some other packages to allow us to continue using this system (see erikdubbelboer/node-sleep#6 and tblobaum/rconsole#7 and https://github.com/cscott/node-icu-bidi and redis/hiredis-node#45 for instance).

If this were the default setup for node-pre-gyp I would be very happy (and I could probably actually get patches merged to hiredis and rconsole).

[springmeyer]

node-pre-gyp master (future 0.5.0) has this feature in place and is ready for testing - mapbox/node-pre-gyp#18

[springmeyer]

@cscott - let me know if you are able to help test.

[springmeyer]

@cscott this is now landed in master.