Is there any way to instruct DCE to `keep` everything that is annotated with `@JsExport` ? Right no...

# javascript

[ankushg]

Is there any way to instruct DCE to keep everything that is annotated with @JsExport ? Right now we're manually maintaining a list in dceTask { keep(…) } , and it's kinda annoying to do so manually.

I know it's possible to write some code to generate the keep declarations for us, but figured it was worth asking the broader community first 😄

[turansky]

• Gradle task (simplest)
• Legacy plugin (for classes only)

[CLOVIS]

If you are making a library, then you should probably let the person using the library do DCE?

[turansky]

DCE - public declarations export filter
1000 public types, but only 200 exported for example

[ankushg]

If you are making a library, then you should probably let the person using the library do DCE?

Our use case is using Kotlin Multiplatform to spit out a JS artifact, and consume that JS artifact from a (kotlin-agnostic) JS project. DCE won't know which methods are used/unused at the time the klib gets transformed into a JS artifact, so we just want to assume that everything we explicitly export is supposed to be kept

[ankushg]

@turansky yeah, probably going to make a gradle task or maybe use MpApt

Just wanted to see if there was something already out there, or if there were plans to add an option like this to DCE directly

[CLOVIS]

The consumer of your API probably has a built-in DCE thing already implemented (I know Rollup & Webpack both do, at least) which will probably get better results because it can remove parts of your API that they don't use—but I haven't benchmarked anything so not sure how well it works

[CLOVIS]

That's what I would do though: let the end user (the one who has the app entry point) setup DCE

[ankushg]

Webpack tree-shaking relies on ES2015 modules, which Kotlin/JS doesn't currently generate 😔

https://webpack.js.org/guides/tree-shaking/

[turansky]

Also root export required for tree shaking