Namespace company modules?

#1

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 Business and 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 :slight_smile:

#2

I don’t have too much to add but I’m also interested in the thoughts of others. I suspect there is something of a dichotomy of preferences, some people like very structured module hierarchies whilst others prefer not to have any “unnecessary” structure. I’m personally in the second camp because I feel it’s easier to change the structure the simpler it is.

Despite that preference, I personally find your current structure fine, I also quite like the visual separation of 1st and 3rd party modules. Perhaps instead of “unnecessary structure” I mean “structure with no obvious benefit”.

Your concern about conflicting with 3rd party modules is fair, though you could always simply rename your module(s) when a conflict arises, it won’t be that much work. There is an open issue concerning resolution in such circumstances: https://github.com/elm/compiler/issues/1625 there it talks about a conflict with two packages having clashing module names, and therefore you cannot import either one and unlike the case with code you own you cannot change either one.

#3

For example these two packages, ianmackenzie/elm-units and gampleman/elm-visualization, can not be installed in the same app since they both contains a Force module.

#4

This is unfortunate as I am eventually considering adding elm-units to my app that already uses elm-visualization.

Note however that it is still possible to use both packages as long as the Force module is not used.

I made another post about the state of conflicting modules with elm 0.19.

closed #5

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.