Expose application configuration

[lptr]

Add it somehow to the generated application.js. Maybe this could be wrapped into a separate "module" (metadata? application?) that modules could require(). This way it could be introduced in a non-breaking way.

[lptr]

cc @barsimatyi

[lptr]

So this is how it would work:

build.gradle:

task packageApp(type: PackageApplication) {
    parameters param1: "alma", param2: "bela"
}

application.js:

define("application-config", [], function() {
return {
    version: "1.0", // auto-generated from Gradle version
    param1: "alma",
    param2: "bela",
};
});
require(["<main-module>"], function(mainModule) { mainModule.main(); });

The module's JS:

define([..., "application-config"], function(..., applicationConfig) {
    // Weird Spaghetti wrapping that exposes applicationConfig as Spaghetti.getApplicationConfig()
    // ...
    ..., function(Spaghetti) {
        console.log("Config:", Spaghetti.getApplicationConfig());
    });
    // ...
});

Console output:

$ node application.js
Config: {
    version: "1.0",
    param1: "alma",
    param2: "bela",
}

[lptr]

Valid point from @gnagy: it's better to not have shared state like this, and only expose this configuration to main(). Here's how that changes the story:

application.js:

define("application-config", [], function() {
return {
    version: "1.0", // auto-generated from Gradle version
    param1: "alma",
    param2: "bela",
};
});
require(["<main-module>", "application-config"], function(mainModule, config) {
    var appConfig = someWrappingOfConfig(config);
    mainModule.main(config);
});

[lptr]

We'd need a SpaghettiParameters class to expose the properties via:

extern class SpaghettiParameters {
    function getParameter(name:String):Dynamic;
}

So an application module could declare its main method as such:

module com.example.test

void main(SpaghettiParameters params)

This would allow obfuscation-safe access to the parameters, too.