For Lua, just to be safe, I fork all my dependencies and when I work on a project I add those forked dependencies as git submodules. Just to feel a bit more secure any dependencies never disappear.
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.
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.
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 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.
Not sure if this is good practice.