Provie JS lib code for a type safe API

I maintain type safe declarations for threejs (ts2kt was insufficient for my use) and I was wondering if it is good practice to distribute the JS library code itself. I.e. should a distribute threejs withing my declarations? Would this in some way interfere with the DCE process from kotlin?

It does not make sense to distribute it with JS sources, because in application we either use CDN to download JS code or use npm + webpack to build a bandle.
We are using a fork of three.kt library ( And we would be quite happy if you would join forces with its author instead of creating a separate project or at least explain how your project is better. It does not make sense to have several projects doing exactly the same thing.

How does your build chain work in general? Do you pull all kotlin js libs from NPM? In my project it is split ATM: Because of DCE, its no longer neccessary to pull kotlin, kotlin-coroutine, kotlin-html from npm but rather declare the dependency in gradle as a normal dependency. DCE will spit out the files in kotlin-js-min where they are packed as part of the normal webpack bundle process.

For libs like three-js, jQuery and so on I use NPM (package.json) to obtain a copy.

My reasoning for this question was as follows: Since my binding is for a specific version of threejs and I guess other people having a similar build chain (DCE activated and setup webpack to consume this JS files) this would make sense. But I’m unsure if DCE would even pick up the JS file? (see other question of mine)

As far as I know, kotlin DCE works only on kotlin code and is applied before webpack bandling, so it does not know anything about js sources. We use frontend plugin for build and it makes sense to work with npm-ditributed version of the library to avoid inconsistencies. I believe that parts of frontend will be soon integrated into general kotlin plugin, so it will be default way to distribute something for browser.

Where did you get that particular insight?
I was wondering whether the kotlin-frontend-plugin was being abandoned because I haven’t seen much activity on it, and I was kind of sad/scared that it was not invested in.

This is very good news if it is in fact being integrated with the core Kotlin plugin.
Since you mentioned only “parts of it”, do you know what will happen with the rest?

It is from slack discussions. Can’t find the reference right now, but if I am not mistaken it was said, that frontend plugin will be integrated with MPP. I think this is the tracking issue:

1 Like

Thanks a lot for the link! Will definitely track it :smiley: