Name conflict between internal module and second-level dependency

My application has a widely used internal module named TypedStruct. We recently added a new dependency that depends on the typed_struct package, which also defines TypedStruct. So now when we use TypedStruct, the module in the dependency seems to win.

Do I need to put a prefix on the internal module and adjust all of the use statements, or is there another way to resolve this? I realize that as an internal module it really should have been prefixed to begin with. (We have a few modules like this that were intended as libraries but never made into proper packages.)

As a side note, shouldn’t Elixir give an error when it encounters an ambiguous use statement, rather than just picking one of the modules arbitrarily? I’m on 1.16.

The rule of thumb is to never define root level modules, each application should use its own based on app name. For example all your modules in your app (if your app is named my_app) should be in format MyApp.*, this is simply because all module names are just atoms and global. The only exceptions you can see with naming is with phoenix, there you have MyApp.* and MyAppWeb.*.

It’s strange that the compiler did not throw an error, because if you would try to define modules with duplicate names in your application, it will not compile.

2 Likes

Yes, do that. There are tools that can do it reliably (they don’t rely on regexes) if there are too many instances to comfortably replace by hand. Shout here if you need pointers to them, I’ve used them successfully.

1 Like