Comment by kakwa_ | Hacker News Reader

Comment by kakwa_ | Hacker News Reader

Parent Full thread

What you say is 100% true, but I would go one step further and not have npm installed on any production server.

And it's not specific to npm, I would do the same with gem, pip, cpan, etc. Not to mention curl http://ex.io/install.sh | sudo bash.

Call me old school, but personally, I would avoid installing anything from language specific package managers. I would instead either build an rpm/deb package for every dependencies as a single package or if it's too complex, bundle the dependencies and the application in one package which deploys the bundle under /opt/.

That way I only have one source to check in order to see what is installed on my systems. Also, rpm and dpkg tends to be far better at managing what is installed by each package, and far better at uninstalling everything during cleanups.

Also, mixing a language specific package manager and a distribution package manager can have unforeseen side effects as the two can step on one another (for example, I ran into issues recently with a pip install python-consul overlapping with a yum install salt-minion as both of them download python-requests as a dependency).

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.

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.

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

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

This is actually why I like working with C and Go. The compilers are on the build server and I just publish the resulting binary on a barebones production server after the build passes. In the past, working with Django, people always gave me shit for vendoring python package as part of the build, but it's to avoid having needlessly complex production environments and to remove the need for package managers.

I like this idea. Can you elaborate a little bit on how/where you would fetch the gem package without the language based package manager, and how this is linked to system deps? For dynamic web application deploys the self-contained binary seems ideal, but I've fallen back on Ansible to properly configure the server dependencies, along with gems that may have system dependencies (e.g. psql).

I've done that for a number of languages (ruby, python, perl, java, haskell, elm, c, erlang, lua, tcl, etc.) and their inevitable "yet another package manager" via nix.

Making them all use hashed fixed input sources without allowing any networking or file access during their build and install phases brings me great joy. That's not only useful for deployment but also so you don't end up with development environments that have subtle differences.

This enables me to focus more on my developer job. Getting things done faster and with confidence. I'm sure at some point, just like with programming languages, people will start to ask for more immutability and reproducibility in their OS as well.

> [...] how/where you would fetch the gem package without the language based package manager, and how this is linked to system deps?

You unnecessarily constrain yourself too much. You don't need language specific package manager at all for deployment. For building a binary package you probably need it, but not connected to network. And then you need it with network for downloading source tarballs to include in source package (SRPM or similar). Note that the source package is an important step, as you want to host all necessary code yourself, without relying on randomly changing policies of package registries like NPM.

The sad part is that language specific package managers cram together downloading, building, and installing, instead of providing them primarly as three separate steps. (You usually can run each separately, but crippled in some whay, e.g. you don't get proper dependency solving for download, or you need to manually order building the dependencies.)

> [...] how [binary packages] is linked to system deps?

Normally. Your application requires libpq.so? You mention it in Depends: (or allow the build scripts to detect that). You need sloccount? You mention it in Depends:. You need crontab entries? You put them in /etc/cron.d and add cron to Depends:.

Or use a container.

Reply on news.ycombinator.com