Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Module name conflicts on a large project #470

Open
Nek-12 opened this issue Jan 8, 2025 · 2 comments
Open

Module name conflicts on a large project #470

Nek-12 opened this issue Jan 8, 2025 · 2 comments

Comments

@Nek-12
Copy link

Nek-12 commented Jan 8, 2025

We're currently using delegated props to define our modules: val featureModule by DI.Module { }

However, a very annoying issue is the java.lang.IllegalStateException: Module "featureModule" has already been imported!

This stems from multiple developers working on different features at the same time.
There are cases where devs develop their features, then merge them to master, which causes the master build to crash on startup, because two developers named their property the same way. If this is apparent during rebase testing cycle, it's annoying, but often it only surfaces after git merges two branches into a master branch, breaking the build on that branch.

Hence the question:

Why are module names needed, is there a way to avoid specifying them or autogenerate them in a more unique manner (e.g. using package name in addition to prop name). Why doesn't koin require module names?

@romainbsl
Copy link
Member

Modules' name are mostly used for debugging, meaning that if you have an error, the content of your DI container on modules can be logged. So, logically, having the same module name, may bring some confusion.

We could use auto-generated ids, with the new Kotlin UUID for example, to check if a module have been imported twice. And keep the name only for debugging purpose, but if all your modules are named "featureModule" it won't help.

package name can not be inferred from a delegated property, and not sure if KMP reflection gives us this information as well.

@Nek-12
Copy link
Author

Nek-12 commented Jan 9, 2025

Indeed, I checked out, and it seems that the DI.Module() is not inline, so we can't use reflection to grab the qualified class name. That's a pity, but not a big deal, not worth the breaking change in my humble opinion.

However, it is definitely not worth to crash the app just because of a module name conflict. Perhaps we can just introduce a debuggable flag or even better verifyModuleNames flag to let the users control whether they really want this crash?

Having duplicate names is totally okay in my opinion if that's the desire of the user. They'll rename them once they realize the issue themselves.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants