Hi friends, here is now my new issue with compilin...

# javascript

[salomonbrys]

Hi friends, here is now my new issue with compiling ES2015 modules :
• The per-file mode generates one .d.ts declaration file per Kotlin file, but thoses .d.ts files are not linked between them. For example, one .d.ts file declares the getUser(): User; function, and another declares the export declare class User . That's because they are in different Kotlin files (in fact they even are in different modules). This makes it impossible for our TypeScript devs to use correctly since they are missing a lot of type information.
• The default per-module mode generates one big .d.ts file which contains all modules definitions (Which feels weird, I expected one .d.ts per module). Each module is still compiled in its own .mjs file. Let's say I have a test project with two modules: export and lib . In this example, Kotlin will generate the test-export.mjs, test-export.d.ts and test-lib.mjs files. The test-export.d.ts file will contain both modules definitions (which fixes the declaration dependency issue) but now there is no way for our TypeScript devs to import declarations in the lib module with their corresponding TS definitions (since they are compiled in test-lib.mjs but declared in test-export.d.ts.
• The whole-program mode generates a single big .mjs file, accompanied by its .d.ts declaration file, which fixes both issues, but this feels like a missed opportunity to properly use ES2015 and segment code properly. Also, the types key is not defined in package.json, so it needs to be added manually (this is true for all modes).
So far, only the whole-program mode seems to allow us to export to TS multiple symbols from multiple Kotlin modules. Is there something I am missing ?

[turansky]

In case of library whole-program - best solution

[turansky]

but this feels like a missed opportunity to properly use ES2015 and segment code properly

Looks like terser responsibility 😉

[turansky]

import { A, B, C, D } from "my-kjs-lib"

// or
import { A } from "my-kjs-lib/A"
import { B } from "my-kjs-lib/B"
import { C } from "my-kjs-lib/C"
import { D } from "my-kjs-lib/D"

In case of Kotlin/JS first variant will produce more compact bundle 😉

[turansky]

1. Better API
2. More compact bundle

[turansky]

Single problem which I see - in some cases you will need more time for Terser (bundle optimization), but it should be big library

[salomonbrys]

So, what is the point of per-module or per-file ?

[turansky]

1. They don't produce umbrella index.mjs and index.d.ts - best API from user perspective
2. Additional initialization guardes inside files
3. File rename in Kotlin -> new import for user 😞

[CLOVIS]

What is the impact of these options on incremental compilation? Naively, I would expect that per-file would be faster in development, since less of the bundle needs to be regenerated?

[turansky]

> Naively, I would expect that per-file would be faster in development, since less of the bundle needs to be regenerated?
I also expect such behaviour.
But it looks like KJS application problem (not library).