If you have a big application and you want to split that application into multiple git repositories to improve testing and shareability among different parts of your site, you’ll need a way to include those various repos in your dev, testing, and production environments. One way is by specifying them as private dependencies in your main repo’s package.json. This has some serious drawbacks though and gets really complicated. Pretty soon you’re creating postinstall hooks and creating symlinks that correlate with Webpack aliases so your imports work in both the main repo and in the library repos. Pretty soon you’re creating really weird include regexes in your Webpack 2.0 module.rules property so that your third party Webpack loaders (such as babel) will scan these in-house libraries that reside in your main node_modules directory. Oh, except mocha-webpack doesn’t seem to honor those loader rules because it’s mysteriously biased against scanning anything in the node_modules directory. And oh, you’re also probably symlinking your node_modules directory into an adjacent local_modules directory that’s gitignore’d so you can do local dev work on them. And of course you can’t use npm link or yarn link for this because those shortcuts assume your environment is your host, when in reality your IDE is in your host but your actual server is in a VM with everything synced back and forth, which means you have to roll the symlinks by hand. Oh, and good luck with getting those symlinks to work as expected on CI.

It’s around this time that git submodules start looking really attractive, except git subtrees are better. This Medium article by a Medium engineer explains subtrees really well.