[Internal API]Compose internal - Breaking changes in patch version - 4.1.0/4.1.1

[Nek-12]

You have another breaking change, this time in 4.1.1-beta, breaking the entirety of LocalKoinScope. It's not clear how to provide it and there was 0 deprecation cycle.

I rely on Koin Scopes to provide a screen destination scope to composables, can you please not break my apps, or at least release 5.0.0 properly according to semantic versioning which you claim to follow.

[hakonschia]

Also wondering about this. If LocalKoinScope is meant to be internal to Koin and there is no non-internal way of providing a scope I'm not sure how currentKoinScope() which is used by koinInject() is useful

[smiLLe]

Same issue. How about we add a KoinScopeUnmanaged which just shares the scope without adding lifecycle stuff.

[amwer159]

Please try to use KoinScope(scopeDefinition = { scope }, content = content). Under the hood it provides LocalKoinScope via CompositionLocalProvider.

[Nek-12]

@amwer159 No thanks. I have 4 other composition locals there along the scope, I don't want to create another composition just to provide a local, esp given that that function does nothing except forward the call and is not properly annotated to prevent the overhead.

[hakonschia]

Please try to use KoinScope(scopeDefinition = { scope }, content = content). Under the hood it provides LocalKoinScope via CompositionLocalProvider.

KoinScope() will always close the scope when the composition is disposed because it uses rememberKoinScope():

koin/projects/compose/koin-compose/src/commonMain/kotlin/org/koin/compose/scope/KoinScope.kt

Line 94 in 37516ff

rememberKoinScope(scope)

We are some places handling the closure of the scope ourself because we sometimes need a Koin scope to outlive a composable (for instance screen rotation or sharing the scope between two different screens), so this does not provide equivalent behaviour to just providing it ourself with LocalKoinScope

I have 4 other composition locals there along the scope, I don't want to create another composition just to provide a local

+1 on this

[arnaudgiuliani]

We’ve introduced a breaking change in Koin’s Compose integration (beta).
The new ComposeContextWrapper replaces the old LocalKoinScope setup to fix “stuck” context issues seen in 4.1.0 and earlier. The original design was clearly buggy for a while, and many proposals were not so great. Now with this ContextWrapper approach, we won't be tied to any LocalComposition side effect.

I see documentation could be better for sure, even the changelog.

Some of you might have relied directly on LocalKoinScope or LocalKoinApplication — those should be treated as internal APIs, and will likely require @KoinInternalApi opt-in going forward. Even it should be completely internal in the next releases.

I will look at backporting stuff in 4.1.2. Another proposal is to let you work around the current Koin scope, with something like UnboundKoinScope that wouldn't be tied to local Composable but would interact with the current scope.

When feedback is needed, we usually post on Kotlinlang Slack (#koin).
Perhaps Slack is not the best place to ask for feedback — I’m open to suggestions (mailing lists, GitHub Discussions, etc.).
It’s perfectly fine to have feedback on beta tracks — that’s exactly their purpose, and it really helps make stable releases smoother. For sensitive changes like this one, that’s even better.

Please share your use case here — it will help us design a better long-term solution.

Thanks for testing the beta and helping refine the Compose integration!