Changing the module's output directory doesn't help if the module also contains static web resources (as explained above). An artifact sounds like it will do the trick though, thanks I hadn't thought of that

You need “Other” artifact type

@alexey.andreev in terms of suggestions, my only one is that it seems that this process could be made simpler through some more sensible, production friendly defaults. I don't think what I'm trying to do is too unusual

@bashor Will I have to unmark my static files as a source directory though (so they don't get copied to the wrong place by IDEA as part of the build)?

could please you share your project and describe what exactly do want to get?

which files do you want to move and which one don't

OK, though I'll make a new one from scratch, give me a few mins

@User uploaded a file: example.zip

In this example, building the module places index.html, webapp.js and webapp.meta.js in the module output dir (build/webapp). I'd prefer the Kotlin output to end up under build/webapp/js instead, because it reflects the way I want the production website to look. See the URLs in index.html - I don't want to have to change those between dev and production deployment.

Note that if I do need to create a build script etc to solve this, it's not a big deal. I'm just surprised I can't start developing with minimal setup, yet still write code that doesn't need changing for production (in this case, the sticking point is the URLs in index.html). So I was asking on here in case I was missing something simple and there's a better/recommended approach.

well, You already changed out dir to

build/webapp

, You can change it to `build/webapp/js`if you want. What is problem? I think it’s good solution

Because then the static resources get copied to build/webapp/js too

My current (temporary) workaround is to set the output directory to src/webroot/js, and unmark src/webroot as a source directory.

That way I can run/debug the app without needing any additional artifacts or other build scripts etc, which is fine for my current purposes (evaluating Kotlin JS). But I'm assuming unmarking src/webroot as a source directory comes with a cost (eg it might break some refactoring and navigation?)

@nhaarman has left the channel

Hi. Seems new milestone's K2JS compiler generates redundant code for inline function's lambda argument. That broke my post-build-step tools badly (details are not important). For example, in code below, function

zzz_caller$lambda

is never referenced, and its body duplicates what was inlined into

zzz_caller

. So, is that as intended or a bug? Source code:

fun zzz_caller() {
    console.log("caller 1")
    zzz_callee {
        console.log("caller 2")
    }
    console.log("caller 3")
}

inline fun zzz_callee(block: () -> Unit) {
    console.log("callee 1")
    block()
    console.log("callee 2")
}

Emitted code:

function zzz_caller$lambda() {
  console.log('caller 2');
}
function zzz_caller() {
  console.log('caller 1');
  console.log('callee 1');
  console.log('caller 2');
  console.log('callee 2');
  console.log('caller 3');
}
var zzz_callee = Kotlin.defineInlineFunction('front.aps.front.zzz_callee_qshda6$', function (block) {
  console.log('callee 1');
  block();
  console.log('callee 2');
}

This is a lack of feature

It's already fixed and the fix will be available in M04

ok, thanks

How does it break your post-buld steps?

well, in post-build step i convert all functions body of which start with literal

"__async"

into generators. then i replace all calls to

__await

function with

yield

. this is my poor-man's async/await 🙂 the problem is that yield keyword is only allowed in generator functions, so now i have JS syntax errors

You can use Kotlin coroutines

yeah, i know. bat this requires quite a bit of change in existing code 😞

You can perform additional check: don't process functions that end with

$lambda

yes. that's probably easiest solution

thanks

the new generated code to js backend is very nice!

but, while you handled the problem of having two classes with the same name

you changed the class name, which will not be a nice feature, when dealing with one or another framework that uses the name