> NPM was written with the assumption that the user would have an active internet connection and the application would be packaged in the same environment in which it would be run, like someone might build for a small project with a basic manual deployment. I ran into a real-world issue attempting to distribute a Node.js application to customers who would then run it in an air-gapped environment on a platform over which I had no control. (Trivial for Java, C/C++, C#, etc). There was no way to pre-package dependency sources and then run the compilation step as a part of the installation to ensure they were built for the right architecture against the available system libraries. These days there are a few tools like npmbox, but they are poor band-aids.
You can use `file:` in your `package.json` to point to your dependencies too if you don't have Internet connection. Also, there's nothing stopping you from including `node_modules` in your project. In fact you can just copy/paste the node packages from one machine to another and have it be portable unless it's a native module.
Checking in node_modules has the same problem as copy/pasting for native modules (on which I was relying, hence the compilation issues). Using file: is a better solution that wasn't around when I first encountered this solution, but still has the problem of requiring you to manually manage every dependency (which can grow to obnoxious proportions in Node). There's no clear way to create the equivalent package of a fat shaded JAR or a statically linked binary.
You can use `file:` in your `package.json` to point to your dependencies too if you don't have Internet connection. Also, there's nothing stopping you from including `node_modules` in your project. In fact you can just copy/paste the node packages from one machine to another and have it be portable unless it's a native module.