My first thought was “What about including node_modules in your version control?” Downside is that the repo would be much larger, but if it’s going to expand to that size on the client after running “npm install”, maybe that’s not a big deal? But it feels kinda wrong to do that...

Committing your `node_modules` is a bad idea. The best answer is to either use an offline cache of package tarballs that have been committed to your repo, or an NPM caching proxy.

Yarn has an "offline mirror" feature built in, and Shrinkpack is a tool that can create an offline mirror based on an npm-shrinkwrap.json file.

I wrote about using Yarn's offline mirror here: http://blog.isquaredsoftware.com/2017/07/practical-redux-par...

I know you can use JFrog/Artifactory to cache pulls of Jar files from maven repos, as well as Docker images. Does JFrog support node?

Yes, JFrog Artifactory supports npm and so does Sonatype Nexus. More info:

https://www.jfrog.com/confluence/display/RTF/Npm+Registry https://help.sonatype.com/display/NXRM3/Node+Packaged+Module...

I haven't actually used an NPM caching proxy myself. It looks like Artifactory does support acting as an NPM proxy. The other tools I've heard of are Sinopia, Verdaccio, and local-npm.

Addy Osmani has a related article at https://addyosmani.com/blog/using-npm-offline/ .

yes: https://www.jfrog.com/confluence/display/RTF/Npm+Registry

yarn's "offline mirror" blog post[1] has been super helpful — I was able to set one up in less than 30 minutes.

[1] https://yarnpkg.com/blog/2016/11/24/offline-mirror/

That would break when going cross platform for modules with native deps.

See npm rebuild https://docs.npmjs.com/cli/rebuild