| I have a FOSS project[0] that uses submodules for two separate reasons: In the first[1], it's to include the project's JS implementation in the project's website. Considering that this would be the only JS code running on the entire site, it seemed like overkill to throw in some newfangled asset manager like Bower just for a single NPM package. In the second[2], it's to include the encoding/decoding test cases alongside the implementations. This way, instead of having to maintain a bunch of independent per-implementation unit tests, I can maintain all the tests in one place, and then have the per-implementation test suites snarf the test cases, and I then know with reasonable certainty that all my implementation libraries have equivalent behavior. There are probably other, "better" ways to do both these things - I could bite the bullet and use Bower for the website, and I could have test suites download test cases on-the-fly - but submodules were the path of least resistance, and I've yet to encounter any significant downsides. ---- [0]: https://base32h.github.io [1]: https://github.com/Base32H/base32h.github.io - specifically /assets/base32h/, which points to https://github.com/Base32H/base32h.js [2]: https://github.com/Base32H/base32h.rb - specifically /spec/cases, which points to https://github.com/Base32H/base32h-tests |