I’m using kotlin js in a node environment (aws lam...

# javascript

[Alex Edwards]

I’m using kotlin js in a node environment (aws lambda), in that env i specify a location where the code is and register a handler which is exported from the js. I currently have this configured with a bit of js boilerplate for each function

const listDiscountController = new ListDiscountsController();

exports.handler = async (event, context, callback) => {
    return listDiscountController.handle(event, context, callback);
};

The way I have this setup is with the constructor defined outside of the handler function to ensure asnyc init operations are only performed on a cold start and not each time the function is called. I’m trying to refactor this to be defined in kotlin (the below code works)

private val listDiscountsController = ListDiscountsController()

@JsExport
fun listDiscountsHandler(event: Any, eventContext: Context, callback: Any): Any {
    return listDiscountsController.handleEvent(event, eventContext, callback)
}

the problem I have is that even if i define the entrypoints in separate kotlin files, if they are in the same gradle project they still get compiled down into the same js file. Is there a way to get kotlin (legacy not IR) gradle plugin to create multiple js files for a project (ideally 1 per kotlin file)?

[anton.bannykh]

Hi! In your particular case couldn't you do something like

private val listDiscountsController by lazy { ListDiscountsController() }

@JsExport
fun listDiscountsHandler(event: Any, eventContext: Context, callback: Any): Any {
    return listDiscountsController.handleEvent(event, eventContext, callback)
}

As for your original question, unfortunately there is no easy way to split the result per-file. The main reason for that are the circular dependencies between files. We are not sure what is the best way to handle that at the moment. I've seen folks overcoming that with a bit of a Gradle magic, where they create projects on the fly based on the file naming schemes, but that's probably going a little bit too far...

[Alex Edwards]

that is probably an option and would likely work. One disadvantage of that approach is that in aws lambda your only billed for execution of your handler function so if you can perform setup tasks outside of that your not billed for them.