TCA Accessory libraries

[tgrapperon]

There are a few accessory libraries out there that are expanding the core TCA experience with additional features.
Without making any supposition about something centralizing them, I think there's a need for common guidelines to follow in order to improve the end-user experience. The objective is not to have something strict that should be enforced at all costs, but rather a common standard one can refer to when needed.

For example:

• How such libraries should be named? swift-composable-xxx, tca-xxx, …?
• How modules should be named ideally? ComposableXXX, ComposableArchitecture_XXX, …?
• Should the library export ComposableArchitecture, or avoid doing it? (i.e. @_exported import ComposableArchitecture)

Even without any centralization, a common set of rules like these may already benefit end-users of such libraries: consistent naming, consistent behavior, discoverability, etc.

What do you think about it? Do you see other requirements?

[tgrapperon]

My personal take about this:

• Libraries should be freely named, or fall back to swift-composable-architecture_xxx or tca-xxx. swift-composable-xxx may collide with unrelated things.
• Modules could be freely named, or fall back to ComposableArchitecture_XXX or TCA_XXX.
• Accessory libraries shouldn't export ComposableArchitecture: this is a stronger requirement that gives more control about what's happening. Many users will proxy their ComposableArchitecture needs through an in-house module that exports TCA and its accessory libraries, as well as custom helpers. Not exporting TCA in accessory libraries should favorize this approach. Otherwise, refactoring may be more difficult, as removing an accessory library in some file's imports may lead to core-TCA types becoming unknown if the library was responsible for exporting them.

These are only suggestions of my own, and I'd be happy to change/adapt them according to others' views on the subject.

[stephencelis]

Hey @tgrapperon! Thanks for starting the discussion.

So far we have 2 "official" TCA accessory libraries, Composable Core Location and Composable Core Motion.

• How such libraries should be named? swift-composable-xxx, tca-xxx, …?

We've been preferring to omit the swift- from these accessory libraries and use composable-xxx (composable-core-location, composable-core-motion). While prefix symmetry is lost with the base library, it's much less verbose.

• How modules should be named ideally? ComposableXXX, ComposableArchitecture_XXX, …?

We've gone with ComposableXXX (ComposableCoreLocation, ComposableCoreMotion)

• Should the library export ComposableArchitecture, or avoid doing it? (i.e. @_exported import ComposableArchitecture)

We've avoided exporting it so far. Exporting can be a bit of a flakey thing in our experience. While we do it a little bit in the core library, we're not sure it's generally a good thing to rely on given that it's still underscored.

[tgrapperon]

Thanks a lot for the feedback! It seems much more concise and natural than my bureaucratic scheme.
I'll go like this from now!

[alexito4]

It would be good if there was a GitHub tag/topic to easily find them ^^ I find it very useful with Publish https://github.com/topics/publish-plugin?l=swift

[tgrapperon]

Indeed! There's a swift composable architecture tag I'm using, but it doesn't seem used by many.