Consider making alert a separate package #271
Replies: 1 comment
-
Hi @klaaspieter, we prefer not to split out such a tiny library just for the alert/text state structs. However, we have realized recently that most of our packages don't actually need to depend on SwiftSyntax directly. For example, in both swift-perception and swift-case-paths we have split the libraries into PerceptionCore/CasePathsCore that holds just the base types and functionality, and then Perception/CasePaths has the macros and SwiftSyntax dependency. This allows one to build libraries that use the tools of Perception/CasePaths without incurring the cost of SwiftSyntax until one actually needs the macros (which typically only app code needs the macros, not libraries). And so that means technically all of swift-navigation could depend on those core libraries and lose the SwiftSyntax dependency entirely. Unfortunately, we |
Beta Was this translation helpful? Give feedback.
-
I use Swift Navigation in all my apps but only for its ability to abstract the concept of an alert. I wince a little every time I see the package resolution pull in swift-syntax or when I enable the macro target (which I seem to have to do constantly). It feels too much to pull in just because I want a slightly more ergonomic way to present an alert.
I understand why it's part of the larger package which is why I'm wondering if you've ever considered pulling the alert functionality out and making it a separate package?
Beta Was this translation helpful? Give feedback.
All reactions