DSL Module Discovery, or @Module support include a module definition by dsl

[lotosbin]

@module support include a module definition by dsl,
ex.

val moduleA = module {
}
@Module(
      includes = [moduleA]
)
class ModuleB 

or @configuration support module definition by dsl

@Configuration
val moduleA = module {
}

[lotosbin]

Technical Analysis

Thank you for the feature request. After a thorough analysis of the codebase, I need to explain why this feature request cannot be implemented as described:

The Fundamental Problem

The requested functionality has an architectural incompatibility: KSP (Kotlin Symbol Processing) operates at compile-time and can only analyze code symbols (classes, annotations, etc.), but DSL modules created with module { } are runtime constructs.

Why This Cannot Work

1. DSL modules are runtime values:

   val moduleA = module { } // This is a function call that returns Module at runtime

2. KSP needs compile-time types:

   @Module(includes = [SomeClass::class])  // KSP can process KClass references
   @Module(includes = [moduleA])  // ERROR: moduleA is not a type, it's a val

3. The includes parameter expects KClass<*>: Looking at the annotation definition (CoreAnnotations.kt:191):

   annotation class Module(val includes: Array<KClass<*>> = [], ...)

   This can only accept class references, not property/value references.

4. KSP cannot resolve runtime values: The includedModules() function (AnnotationMetadata.kt:107-110) retrieves KSType (Kotlin types), which doesn't exist for val declarations:

   fun includedModules(annotation: KSAnnotation, fieldName : String = "includes"): List<KSDeclaration>? {
       val declaredBindingsTypes = annotation.arguments
           .firstOrNull { it.name?.asString() == fieldName }?.value as? List<KSType>?
       return declaredBindingsTypes?.map { it.declaration }
   }

Current Workaround

You can manually combine DSL and annotation-based modules at application startup:

// DSL module
val dslModule = module {
    single { MyService() }
}

// Annotation-based module  
@Module
class AnnotatedModule

// At startup
startKoin {
    modules(
        dslModule,          // DSL module
        AnnotatedModule().module  // Generated module
    )
}

Recommendation

This issue should be closed as "won't fix" or "by design" because:

1. It's architecturally incompatible with how KSP and Koin Annotations work
2. The current manual approach provides the same functionality
3. Implementing this would require fundamental changes to how Kotlin annotations and KSP work (which is outside of Koin's control)

If you strongly need this pattern, consider using annotation-based modules exclusively, which are designed to work together through the includes parameter.

[lotosbin]

ex.

@Module
@Configuration
val moduleA = module { } // This is a function call that returns Module at runtime

generate a wrapper module class

class moduleAModule {
}
moduleAModule.module() { return moduleA}

or

@Module
@Configuration
class Module{
val dsl = module{
]
}

Module class generate will default include dsl, so we can bridge Annotation-based module with DSL module,

we use @configuration auto scan feature to implement plugin system,
so manually combine DSL and annotation-based modules at application startup is not worked.

[lotosbin]

found a worked solution,

@Module
@Configuration
class MyModule {
    val module: org.koin.core.module.Module
        get() = module {
            includes(bootModule)
        }
}

direct declared property method will override generated extension property,

[lotosbin]

migrate to koin compiler plugin,
and this solution is not work

[lotosbin]

InsertKoinIO/koin-compiler-plugin#21

[lotosbin]

Temporarily use sweetspi to implement dsl module discovery, I hope koin can directly support

internal var userModule = module { 
    // ...
}
@ServiceProvider
object UserPlugin : Plugin {
   fun module() = userModule
}
val pluginModule = modules {
  includes(ServiceLoader.load<Plugin>().toList().map { it.module() })
}