Its good to have dependencies archived for continued access to them, but there are efficiency issues with doing that. Using git submodules (or vendoring or similar) means that you and everyone who uses the project is stuck on the exact commit you have chosen for each submodule until they go and modify the git tree to use a different commit for each submodule. This makes it higher friction to update a submodule. You can't just go `git pull` or `apt upgrade` to update the submodule, you actually have to go modify every project that uses the submodule, update and redeploy each one, instead of just updating and redploying the submodule itself.

That sounds amazingly slow, in a good way.

Well, I only use git submodules in private projects. From what I read most devs hate it :)

In the past I did came into contact with git submodules through freelancing for another company, and I agree it was quite a hassle it times using it in a team setting.

Even in private projects, its an additional hurdle that can block things like security updates for example.

With node some people commit the heresy of comitting the whole node_modules folder.

I would do that, but node puts compiled bits in there, so nothing works if you switch machines.

It's not like linux distros figured out this stuff was an issue decades ago...

I think that's called vendoring and it's part of the 12 factor app.

Good luck with that approach in the JS world, where a package can have, without exaggeration, a thousand and more dependencies. Hopefully in the Lua world things are saner.

I’ve found most Lua game related libraries don’t have any dependencies, so it’s indeed a saner world :)

What about transitive dependencies?

I've found most Lua libraries don't have any other dependencies.

Perhaps this is the reason I've found this approach work well with Lua. I've never tried it with other languages that I use, like Swift, Objective-C, C#.

I did work in a company in the past that used Nexus [0] for their dependencies across various platforms. Perhaps Nexus has some tooling build in to deal with transitive dependencies, not sure.

---

[0]: https://www.sonatype.com/products/nexus-repository

It's forking all the way down. I run my code on a fork of Linux, just in case.