I work at a company called Zaptic and our internal modules are namespaced in a few different ways. We have some core domain types & decodes (eg. Users, Campaigns, Teams, Reports) under a
Data. namespace so:
Data.User Data.Campaign ...
We also have two main Elm apps called
Users so we have:
Business.UnitType.Model Business.UnitType.View Business.LocationList.Update Business.Model Users.Team.Model Users.View ...
We also have a series of utility modules under a
Zap namespace. So:
Zap.Upload Zap.File Zap.Icons ...
This is a mixture of legacy (I think
Data was perhaps inspired by Haskell’s
Data. namespace though I feel that is probably more for reusable generic data structures) and copying NoRedInk (I think they have a
Nri namespace for some stuff?) and then just have actual apps that feel like they should be top level.
My question is, how do you all approach this? Similar strategy or notably different? I also have a colleague who feels that we should try to remove the top level namespaces but I’m concerned about conflicting with 3rd party packages and honestly I like the visual separation of 1st & 3rd party packages in the
import block. That said, we do a lot of
import Data.User as User and both feel it would be nice to have
import Business.UnitType.Model as UnitType.Model but you can’t have dots in aliases (probably sensible!)
Anyway, this all comes up in conversation a bit between my colleague and I and it would be great to have some other voices and input around different strategies to help us move the conversation forwards