Hacker News new | past | comments | ask | show | jobs | submit login

Same here. Like I said above [below?], I generally despise submodules, but that is one thing that makes them easier to deal with, than packages.

For example, in the project that I'm working on now, I have refined the app's "business logic" to an SPM module that I integrate, through GitHub.

The idea is that I don't change the logic, and I enforce that, by using it as an SPM module.

However, every now and then, I encounter a bug in this module, or I find the need to add something to its API. When that happens, I need to exclude the module from the dependency list in the project, include it directly, as a local link, and work on it that way. Committing is a separate task from the main app (Xcode allows aggregate commits, but Xcode's Git integration is so poor, that I don't use it).

It actually works well. A submodule would also work well, with more Git integration, but the drawbacks far outweigh the advantages.




Alone is ok. You know what you want and own that work flow. North of maybe five people this tends to break down fast.


I've had it work fine on large teams. The rule for me is that if contributors to the repo are as likely to change the submodule as the repo itself to resolve any given issue. More succinctly, submodules are for internal dependencies we might change. The reason being that with some package managers and languages doing small incremental changes to a dependency as you try to resolve an issue is a lot of extra typing vs it just being in a submodule.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: