One Package vs Many #115
Replies: 1 comment
-
Hey @CraigSiemens, for us it was mainly to reduce maintenance burden. One SPM package means one directory structure, one Package.swift, no cognitive overhead to figure out which library belongs to which package, and it's super easy to have modules depend on each other when they are in the same package rather than spread across many packages. We haven't yet seen a clear reason why multiple SPM packages would be preferred. The pros that you list above are, in my opinion, a little theoretical. Multiple packages will group things together, but that comes with the burden of knowing what exactly you want to group. Depending on how granular or broad you want to be with the packages you may just end up with a lot more churn of moving libraries around to different packages. And pulling packages out into their own repo is a rare event (the majority of our libraries are specific to just isowords), and so we don't think we should optimize for that use case. These of course are just our opinions. Whether you use multiple packages or a single package, the most important thing is to modularize your code base 😄 |
Beta Was this translation helpful? Give feedback.
-
I noticed the project has one big package with multiple targets. I was wondering what you think the trade-offs might if using more smaller packages instead of one larger one. This is what I've noticed so far but was curuisous if there were any more I was missing.
Pros
Cons
Unknowns
Beta Was this translation helpful? Give feedback.
All reactions