I would expect to do something like: ``` task app1(type: KtolinJsDce) { dceOptions { outputF...

# javascript

[gaetan]

I would expect to do something like:

task app1(type: KtolinJsDce) {
		dceOptions {
		    outputFileName = "app1"
		    keep = "mod.app1.start"
	}
}

[Ilya Goncharov [JB]]

Yes, it is possible
But KotlinJsDce task is Compile in terms of Gradle
You need to define some properties for that
- source
- classpath
- destinationDir

Basically, you can find source in your compileTask
Classpath can be classpath of compileTask
And destinationDir is basically destination dir of your dce’d javascript files (seems that you can not to set dceOptions.outputDirectory
Finally, you get something like this

val app1 by tasks.registering(KotlinJsDce::class) {
    val task = tasks.getByName("compileKotlinJs") as Kotlin2JsCompile
    source(task.outputFile)
    classpath = task.classpath

    destinationDir = File("$buildDir/app2")
    dceOptions {
        keep += "test-app.org.my.foo"
    }
}

Could you please provide some information about your use case? Maybe we can make it more convenient in future

[gaetan]

My needs concern https://play.data2viz.io, which is entirely in Kotlin, backend, and frontend. The website uses server-side rendering for better search engine optimization. When the browser loads the page, it also loads Kotlin/JS code for front end interactions. I want to optimize the size of the JS file, to limit the bandwidth but also the code that the browser needs to parse.

[gaetan]

I’m still using groovy DSL. How can your code is translated into groovy? 🙏😅

[Ilya Goncharov [JB]]

And you need different DCE tasks with different keep declarations because you generate multiple files with different public JavaScript API, that you return in different cases, am I right?

[gaetan]

Yes. My entrypoints are different but part of the client and common code is shared.

[gaetan]

I hope that, in a “near” future, tree shaking will be done at a higher level (IR) and we’ll have some really optimized js files.

[Fudge]

I wonder why tree shaking is implemented in the Javascript level in the first place, when it can be useful for all platforms? 🤔

[gaetan]

I guess the first design of the language compiler and tools didn’t imagine all the use cases. As you see in this thread we still need to share our use cases.

[gaetan]

@Ilya Goncharov [JB] Could tell me how your Kotlin DSL snippet would be written in Groovy DSL?

[Ilya Goncharov [JB]]

Sorry for delay, I am not so good in Groovy DSL
I think, that except of cast, that should be similar
You can try simply
source = tasks.named(“compileKotlinJs”).outputFile
classpath = tasks.named(“compileKotlinJs”).classpath
destinationDir = ...

Basically, I think, it should look something like this

[gaetan]

Thanks a lot, I’m going to try.

[gaetan]

This build part is really painfull. It’s the task where you loose the most of your time during a Kotlin development. Kotlin DSL performances are too bad, Groovy DSL lacks of example, not enought documentation/example on the new/current MPP plugin and there is already a new one in preparation… 😓

[gaetan]

At the end, I’m still asking myself if the old MPP plugin wasn’t the right way of spliting code. In my case, I would have as much Kotlin/JS projects than KotlinDCE produced apps.

[Fudge]

I really hope they are working on improving autocompletion performance, both in .kt and in .kts .

[gaetan]

@Ilya Goncharov [JB] I created an issue to keep a trace of the use case: https://youtrack.jetbrains.com/issue/KT-34595