I couldn't start this task, but @Gustavo Barbosa Barreto will do it! ;)

[PT-BR] Publiquei um novo artigo "Conhecendo o Koin Annotations" https://dev.to/pedrofsn/conhecendo-o-koin-annotations-5d45 [ENG] Comming soon 🙂

What is missing to functions

lazyModules()

and

waitAllStartJobs()

drops the

@KoinExperimentalAPI

and becomes stable?

I know, what I'll ask is weird, but there is some way to avoid Koin compile safety fails in compile time because of non-annotated dependencies? I'm bypassing like this:

@Module
@ComponentScan("<http://br.com.custom.secret.app|br.com.custom.secret.app>")
class MyModule {

    @Factory
    fun getNonKoinAnnotatedAppLog(): AppLog {
        return GlobalContext.get().get<AppLog>()
    }

    @Factory
    fun getNonKoinAnnotatedGson(): Gson {
        return GlobalContext.get().get<Gson>()
    }

}

A proposed of flatten modules function PR : https://github.com/InsertKoinIO/koin/pull/1801

Hello all, I'm working on Koin 3.5.4 - First RC1 is out https://github.com/InsertKoinIO/koin/releases/tag/3.5.4-RC1

I'm interested to have you feedback on this version, testing anything i working in version 3.5.4-RC1 I need to be sure that on ViewModel API, there is no breakings: https://github.com/InsertKoinIO/koin/pull/1809

The previous API has been too open, and could allow from inject in Activity/Fragment scopes .... which leads to memory leaks. I have introduce ViewModel scope then and ViewModel are created regarding the standard Android API, and Koin root scope

Is there any scope for koin-annotation for wasm

So I created a bugfix PR but the macos builds are failing even though I didn’t touch them, the changes were all in the android packages. Is there something I’m missing that would explain the failure?

Hi folks, I'm new to using Koin. So I've pocked around the source code a bit and found some places I'd like to change. What's the best flow to discuss whether it should be done at all and to gain more context on why it was done this way in the first place? To create an issue and discuss questions there, or to create pull request and discuss there? Changes I'd like to propose mostly concentrate in

InstanceFactory

and code around it, specifically: 1. Changing upper type of generic T in

InstanceFactory

to

Any

- this prevents module definitions from returning null, especially when

SingleInstanceFactory

already uses null to check whether it was initialized; 2. Changing synchronization in

SingleInstanceFactory

and

SingleInstanceFactory

-

get

and

drop

aren't covered by synchronization, so theoretically race condition can happen; 3.

ScopedInstanceFactory::dropAll

does not call onClose callback, is this an intended behavior? 4. Remove

isCreated

method from

InstanceFactory

- it's really has to be used only in tests (it's not as common behavior of inheriting classes) and we can easily remove it; 5. Inline

KoinPlatformTools::synchronized

at least inside common module it can be inlined; 6. Add synchronization to `get`/`getOrNull` methods of native:`MutableGlobalContext` and jvm:`GlobalContext` .

I will push some raodmap updates here. Just checking format/tool to help track and open topic for contribution

Hello, I've created PRs about editing docs. 1. added author docs 2. capitalized first character in docs It's been a while since I created the PRs. I found the process of PR lately. thank you

Your PRs have been merged

Hello everyone! I’ve been reviewing koin-androidx-startup, and I think it’s great that they’ve included support for Android Startup. I know it’s their first version, but I’ve left an issue with some improvement suggestions here. I appreciate your feedback.

Hi folks! I’ve opened my first PR to Koin PR: https://github.com/InsertKoinIO/koin/pull/2020 GH Disussion: https://github.com/InsertKoinIO/koin/discussions/1507 Issue: https://github.com/InsertKoinIO/koin/issues/1510 Message in #C67HDJZ2N I sent by mistake: https://kotlinlang.slack.com/archives/C67HDJZ2N/p1728671967689479 (just to connect threads)

Enqueueing content for 4.0.1 right now loading

I was looking at implementing the

@PostConstruct

and

@PostDestroy

from JSR-330 for koin Would this method in the

abstract InstanceFactory

be the right place? I was planning on looking on the instance's class for the relevant annotated methods, and then invoking the

@PostConstruct

immediately after a non error invocation of

create

And then inside the

drop

method, invoke the

@PostDestroy

method Is this the right approach?

Hey @arnaud.giuliani 👋 happy new year! I've made a small PR to solve this issue, which I also encountered on my own project using KSP2. I've published to my maven local and this fixes the bug the issue raised Think we could have it in the

2.0.0

release?

I'm working on an implementation of a Junit5 ParameterResolver that will enable injecting of koin-managed instances into tests, similar to how koin manages injection elsewhere For example:

@ExtendsWith(ThisNewKoinExtension::class)
class MyIntegrationTest(
	val someService: Service,
	val someRepository: SomeRepositoryInterface
) {
	// tests as usual
}

I have the bootstraps of it working well. Working on some tests for it now @arnaud.giuliani this something you're open to including? I'd prefer to keep it separate to the existing ParameterResolver we have, as that overloads the start/stoping of koin

set the channel topic: Contributing together to Koin with KFIP - https://github.com/InsertKoinIO/KFIP/

Hello all, I've opened Koin KFIP repository to open new features and improvement process for Koin. Next features/big improvements will go through this. This chat is the perfect place if you are interested ✌️

Proposing an alternative to

KoinApplication

compose function, with

KoinMultiplatformApplication

to handle automatic context & logger for every platform (especially for Android). No need anymore to have a specific config for android with

androidContext

&

androidLogger

https://github.com/InsertKoinIO/koin/pull/2114 (for those who want to give feedback)

I'm preparing also a KFIP proposal for Set/Map values injection, following up https://github.com/InsertKoinIO/koin/pull/1951

Currently unqueueing all issues about Koin Annotations 2.0. Will work on it over next week

Hey, I just opened a new PR that fixes an issue on the new custom qualifier annotations feature that I've added (which was released in 2.0.0-Beta3): #211 Since from my point of view it is more of a fix than a new feature I assumed I could directly open a PR.

Hello 👋 I'm testing a Koin patch to solve Compose context initialization. There was previously an issue with Confetti's wear tests and some Compose UI tests. I've tested locally and this patch is working. I would like some checks from someone else, to help me confirm that this compose context initialization is now ok. The test is to use Koin

4.0.3-Beta1

- You can even remove

KoinAndroidContext

or

KoinContext

from your App. https://github.com/InsertKoinIO/koin/pull/2138

I may look at contributors, to help add "standard" annotation to Koin, in 2.1. If some of you already contributed, and interested to continue 👀

@arnaud.giuliani noticed an edge case bug with generating nested class type bindings

interface Foo {
	
	@Single
	class Bar : Foo {
	
	}
}

Results in:

single() { _ -> org.koin.example.Bar() } bind(org.koin.example.Foo::class)

But the correct format would be:

single() { _ -> org.koin.example.Foo.Bar() } bind(org.koin.example.Foo::class)

Note the parent class in the fully qualified path for the constructor

After Compose 1.8 integration, Ktor 3.2 DI Integration work is landing Koin / Ktor DI integration is ready - https://github.com/InsertKoinIO/koin/pull/2196 It's working on the workshop - https://github.com/arnaudgiuliani/ktor-workshop-2025/commit/8d73ab7c03c816a1b5ce2e42feed8380f6e0ae41