A modern programming language that makes developers happier.

kotlinlang

I would expect to do something like:
```
task app1(type: KtolinJsDce) {
		dceOptions {
		    outputFileName = "app1"
		    keep = "mod.app1.start"
	}
}
```

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

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.

I’m still using groovy DSL. How can your code is translated into groovy? :pray::sweat_smile:

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?

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

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.

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

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.

<@UAG4QQZB6> Could tell me how your Kotlin DSL snippet would be written in Groovy DSL?

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

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… :sweat:

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.

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

<@UAG4QQZB6> I created an issue to keep a trace of the use case: <https://youtrack.jetbrains.com/issue/KT-34595>