So i was reading through the koin docs, because we're currently on anvil, and we're having to use th...

# koin

[mattinger]

So i was reading through the koin docs, because we're currently on anvil, and we're having to use the forked version to support kotlin 2.0. As such, we're evaluating other options, as we have no clear timeframe for when anvil itself will support the k2 compiler. One thing i'm not seeing that was able to do with anvil was to discover modules at runtime without an explicit reference to them, but it seems like you have to enumerate them all inside of your startKoin call. Just want to confirm i'm not missing anything

[withoutclass]

IMO having to set them all in in the startKoin block is more of a pro than a con

[withoutclass]

You know exactly what modules are loaded

[mattinger]

This is true to some extent, but it does create issues in maintaining test components. However, the one thing that does help here is the ability of koin to allow overriding objects in the graph (which they call components it seems) by adding additional modules later on that can overwrite them. Yes, this can be dangerous, but it's a nice thing to have. Anvil managed this sort of thing by doing module replacement and/or exclusion.

[withoutclass]

If your test components require injection you may have other design issues going on

[withoutclass]

Unless it’s UI testing I guess

[withoutclass]

But creating fake modules and loading them up is trivial, and so is unloading modules

[withoutclass]

Also if you’re shopping for service locators/DI tooling, something to keep in mind about Koin is they have a really bad track record of backwards compatibility so if you run lot’s of modules/poly repo you’re going to have a bad time

[withoutclass]

It also shows up in other fun ways like if an SDK developer has used Koin internally and that version is different then it will cause crashes

[mattinger]

We are a pretty complex setup, with several system boundary type things being mocked, such as http calls (via okhttp mock interceptor), firebase config, etc.... We currently create certain objects and then bind them into our tests via @BindsInstance in the test component factories.

[mattinger]

I think koin will work still, but it's a big migration no matter what we do. Obviously i'd prefer anvil to complete their work for K2, but that's out of my control, and they are volunteering their own time, as i don't think it has any real corporate backing in terms of dev time and money from square.

[mattinger]

I'm just evaluating what my possible alternatives are

[withoutclass]

Yep that’s why I wanted to point out the issues we’ve been running in to. We run a poly repo with 35+ published artifacts now and we’re effectively stuck on Koin 3.1.6 unless we migrate and publish every single library all at the same time

[mattinger]

Luckily we're a mono repo for the most part, with a few outliers still, but nothing that we can't handle. Also, we let renovate handle that kind of mass upgrade for us when we have dependency updates that need to trickle through multiple repos

[withoutclass]

just being in a monorepo will save you there, unless any incoming dependency also uses it