Hi all! I've got a Kotlin multiplatform project fo...

# javascript

[audax]

Hi all! I've got a Kotlin multiplatform project for an SDK. The project has a package "sdk" and "sdk-testing" for testing-utilities that are used by consumers of my library. One of the consumers is a react application in TypeScript.
My SDK uses KoinDI internally. The "sdk-testing" module exposes a function which loads a pre-configured Koin Application.

When I run this function in React and then use a class from the "sdk" module which accesses the GlobalContext of Koin, the GlobalContext is empty. This is because my "sdk-testing"-module has it's own instance of the Koin-library which is not shared with the "sdk"module.

I would like to expose 2 NPM modules with access the same libraries. Is that possible at all?

[Edoardo Luppi]

If I actually understood what you're trying to do, you'd need a third library to expose the DI context, and then have the other two libraries consume that context.

But in general terms no, exporting to a JS package will always generate a standalone (meaning no dependencies) artifact.

[audax]

Thanks, that was my suspicion. Even I made a third library for the DI context, then I'd have the same problem because that library would also be included in the js library export of my SDK and the SDK-testing module >.<

[audax]

My goal is to not export my testing utils in the final web application. So maybe I just… switch out the dependency in JS, so that my tests run with "SDK-testing" instead of "SDK" as their dependency, but aliased to the same name.

However, that feels wrong

[Edoardo Luppi]

> Thanks, that was my suspicion
Yeah it's a tricky situation and probably close to impossible to resolve in the status quo.

> a third library for the DI context, then I'd have the same problem because that library would also be included in the js library export
You need to work through interfaces to avoid creating a package that include everything.

For example, we could have:
• LibA - exports a createSocket function and a Socket interface
• LibB - exports a initConnection(socket: Socket) function
• LibC - exports a initConnection(socket: Socket) function
LibB and LibC depend on LibA, but only use the Socket interface.
In JS, we can then have:

const socket = libA.createSocket();
libB.initConnection(socket);
libC.initConnection(socket);

[Edoardo Luppi]

However I'm not sure how Koin works, and how it creates its context. So this might not be applicable.

[audax]

The Koin context by default is a static global >.<

[Edoardo Luppi]

A global attached to the window / globalThis, or a "global" scoped to the library?

[audax]

scoped to the library

[audax]

I probably just have to redesign the library boundaries, so that my testing module is actually independent.

[audax]

It's not a big deal that the testing-module has it's own instance of the SDK module, I just have to be careful when dealing with globals/statics

[Edoardo Luppi]

Can you export a function that returns it? You can't probably export it directly as it's not `JsExport`able, but you can create your own entry points to set/override the DI context.

[Edoardo Luppi]

But yeah I'm not knowledgeable enough with Koin so I won't expand further as the direction could be completely off.

[audax]

Uhhh…
import { getRefToActualSDKKoinLib } from "sdk"
and then pass this to my testing library to use.

[audax]

That's a bit dirty, but it could work 😄

[audax]

Meh. event when doing something nasty as this, I've got another big problem: The interfaces from "sdk-testing" are not the same as the ones from "sdk", so my when-branches and all the instanceof checks don't work

[audax]

It must be packaged in a single module…

[Edoardo Luppi]

so my when-branches and all the instanceof checks don't work

Ahhh yes, indeed. Forgot about this "small" detail : (

[audax]

My solution: jsMain of the SDK includes :sdk-test and I rely on dead code elimination.

[audax]

Thanks for the help @Edoardo Luppi! :)