Folks, please vote for this issue: <https://youtra...

# javascript

[pabl0rg]

Folks, please vote for this issue: https://youtrack.jetbrains.com/issue/KT-16604
Kotlin would never have gotten anywhere on the JVM if compiled jars were not usable from Java source.

[Dominaezzz]

It would become another Scala I guess.

[Dominaezzz]

I'm pretty sure that feature has been implemented though.

[Casey Brooks]

It will be available in 1.4, look for “Preview: Typescript Definitions” in the 1.4-M1 release post https://blog.jetbrains.com/kotlin/2020/03/kotlin-1-4-m1-released/

[basher]

Yep you can test it out in 1.4-M1 with the compiler in IR mode.

[diesieben07]

The opposite way (JS and TS from Kotlin) is still missing though.

[Dominaezzz]

That has also been implemented. (Just not very feature-ful)

[diesieben07]

Not in the compiler, has it? You need to run an external tool (which I can't remember the name of, starts with a "d" I think...).
And the code it produces for anything more than left-pad is borderline unusable.
Which, honestly, is not completely its fault because things like type Foo = "bar" | "baz" | true simply cannot be represented in Kotlin at the moment

[diesieben07]

Dukat, thats the name

[Dominaezzz]

Would Dukat directly in the compiler be useful?

[Dominaezzz]

I guess a plugin wouldn't kill

[diesieben07]

Uhm, yes? Ideally the experience when writing Kotlin for JS should be comparable to that when writing Kotlin for JVM.

[diesieben07]

The Kotlin compiler should natively understand JS and TS code, like it does JAva.

[Casey Brooks]

I believe they’re working on integrating it directly into the Multiplatform/JS toolchain. When you declare an npm() dependency, it will run Dukat automatically

[diesieben07]

That would be a good start.

[diesieben07]

But at the moment the JS side of Kotlin doesn't integrated with existing JS tools. At all. It's like a sore, cancerous growth that replaces everything instead of using existing toolchains. Which is really unfortunate, because in the Java world Kotlin really excels at this.

[Casey Brooks]

Personally, I believe that to be more a deficiency in the JS tooling ecosystem more than Kotlin. JS build tools work by building a large “project model”/AST/etc. and then run a bunch of JS code transformations over that. It’s not a series of independent CLI tasks like most software toolchains are, which makes it very difficult to plug anything else into those toolchains. And even the steps that are CLI tasks are still NPM CLIs that tend to make assumptions based on having a complete package.json, which means any other tools need to generate that file to work with it

[diesieben07]

Not really. The build tools you are talking about are web bundlers (like webpack). The closest equivalent to Kotlin in the JS world is Typescript (a language that compiles to javascript). What does the typescript compiler do? tsc foo.ts generates foo.js. It does _one thing_: Compile typescript to Javascript. It doesn't bundle files together.
This allows it to integrate perfectly with things like babel (which can just read the generated Javascript) or Webpack (if you want to generate stuff for the web) or node.js (which will just use the generated js files).
Kotlin instead insists on always generating one giant JS file for all your code inclusive of libraries. This is just strange.

[bashor]

Starting from 1.4-M1 you can get d.ts files when using the new compiler backend, for more information take a look at the blogpost https://blog.jetbrains.com/kotlin/2020/03/kotlin-1-4-m1-released/#exporting-declarations-to-javascript

[bashor]

Also, look at pinned messages.

[diesieben07]

The generation of d.ts files is a huge step in the right direction, I will be trying it out tomorrow.
But its only part of the story

[bashor]

Starting from 1.3.50 you can turn on experimental auto generating declarations for npm deps (using Dukat), see https://blog.jetbrains.com/kotlin/2019/08/kotlin-1-3-50-released/

[diesieben07]

I will also try Dukat again, but last time I tried to use it the code it generated was just either completely broken (didn't compile) or unusable (Any everywhere).

[diesieben07]

Is there a reason that you are sticking with generating declaration files instead of making the compiler understand JS and TS directly, like it does with Java?

[bashor]

It requires a lot of work at the start and not only in the compiler but in any tooling, especially in IDE. Also, it will become constant running after TS.

[diesieben07]

Well, I'll take your word for it.
Like I said I'll give Dukat another try and see if it works better now.

[bashor]

Also, for direct integration into the compiler, we must guarantee that everything in TS could be expressed well and conveniently in Kotlin.

[diesieben07]

You can always fall back to dynamic 😉 But this is just me ranting from an outside perspective. I wouldn't want to be in your shoes