-
-
Notifications
You must be signed in to change notification settings - Fork 50
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
Allow annotating external module dependencies for fine-grained opt-out from compile checks. #95
Comments
Still wondering why you can't access a definition that would be included in your Koin ktor app module? Or is it more here a problem of mixing Annotated/DSL config? |
Yes. I can access the definition at runtime, and everything works as expected from a DI point of view. While this mixing of annotations and DSL would work at runtime, the |
ok, something that would be "ignored" for safety check |
I have the same problem :( |
I am having a similar issue here #126 |
the global idea is accepted. Don't know yet if we can call it |
Same issue here - It would be good to have a way to exclude certain deps from compiler checks |
Here is a PR with |
@arnaudgiuliani , I updated my personal repo to use the new annotation |
Is your feature request related to a problem? Please describe.
When enabling the
KOIN_CONFIG_CHECK
flag, the compiler will check the modules for completeness at compile time, which is great. However, I have encountered a gotcha when working with Ktor.I would like to be able to build dependencies based on the application config, such as a database connection:
Since Ktor applications are scoped, there is no place to get the config from globally (and would also make it painful to test), so I register the config at the time of installing the Koin feature and have a reference to the environment:
This works perfectly at runtime, but the compilation now fails because KSP can't know that I will provide a separate module with the dependency at runtime or not.
Describe the solution you'd like
I do not want to disable the entire KSP checks for this one workaround. Instead, I would like to have an annotation that allows me to opt out of a check for a particular inject, and that it should just assume that it is available when validating the rest of the module.
This would document in code that I intentionally defined an external dependency and I am aware that I am responsible for ensuring its runtime availability, something like:
Describe alternatives you've considered
I have tried to see if it is possible to pass the config as a constructor parameter to the module, but code generation does not like it, and it makes sense since that would break the
@Module(includes = [])
feature, which expects a class reference with a no-args constructor.I also tried to include the config module into the database module programatically, and while it works at runtime, it is again too late because the issue happens at compile time.
Target Koin project
Koin Annotations
The text was updated successfully, but these errors were encountered: