You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
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.
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.
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?
The text was updated successfully, but these errors were encountered: