[thom_nic]

The ironic part here is, part of npm's core design - installing all deps to `./node_modules` - makes it extremely easy to "build" on one machine and then zip up the whole project directory which only needs `node` to run.

This is in fact way easier than options for python, ruby (and probably many others) which tend to install versioned dependencies to some shared directory and then add them to the path at runtime. So you're very right, it's trivial to not need npm at all, ever, in production.

[dvlsg]

Unless you have native modules and are building on a machine that is different (windows, etc) from your deployment target.

And sure, there are ways around that too, but it's not always as simple as copying and pasting the dependencies.

[zeveb]

> Unless you have native modules and are building on a machine that is different (windows, etc) from your deployment target.

I really don't understand why people do this. If you deploy on Linux, develop on Linux (and if you deploy on Debian, develop on Debian); if you deploy on Windows, develop on Windows (and you have my sympathy). It just makes all of life so much easier.

As a side note, I'd argue very strongly against picking the deployment environment based on the development environment: choose the best deployment environment, and then specify that developers use it to develop. IMHO there's no deployment environment today which is unsuitable for development (with the exception of Windows, ba-dump-ts), and production is what makes the money and keeps the customers happy.

[thom_nic]

This is true. Thankfully node-pre-gyp helps here because you can build the native modules once for each target arch/platform. I actually have a node app that uses several native modules, and `npm install` it for an ARM target from an x86 host. It also works cross-OS (e.g. build on MacOS for linux.) The key flags are `npm install --production --target_arch=arm --target_platform=linux`.