submodules always seem good in theory, but fall apart anytime they need to be updated on a regular basis as part of a dependency ecosystem. We tend to use them

submodules always seem good in theory, but fall apart anytime they need to be updated on a regular basis as part of a dependency ecosystem. We tend to use them as shorter term solutions when we have something we know we want to be an “official artifact” eventually but don’t want to spend the overhead setting up a build/publish for that library. In the sense of working with git submodules, it can be quite painful sometimes, as most HN readers here know. The process of installing and updating them, in my experience, does not follow the principle of least astonishment. When dealing with a project using multiple submodules and switching between different branches, it’s difficult to get the right combination of submodule dependencies on the first try. submodules are a tool like any other and should be used as such. For us that usually means that we want to make a semantic separation between two different projects but in reality that only one project uses another for awhile and so it makes sense to have the less overhead of the submodule dependency vs “real” dependency.