Provide JS modules for making the configuration easier

[ppcano]

From Slack:

can anyone point me at some useful examples of changing the region(load_zone) the cloud instances created in? I'm running a k6 script and have tried the option detailed without any luck.

A few ideas came after reading the comment. Draft ideas:

1. I think it could be available a JS module to facilitate the load zone configuration.
   The list of options are https://docs.k6.io/docs/cloud-execution#section-cloud-execution-options

import { loadZones } from 'k6/cloud';

export let options = {
    ext: {
        loadimpact: {
            name: "Hello k6 cloud!",
            distribution: {
                scenarioLabel1: { loadZone: loadZones.ashburn, percent: 50 },
                scenarioLabel2: { loadZone: loadZones.dublin, percent: 50 }
            }
        }
    }
};

This particular module could make the info available like:

console.log(loadZones)

I reviewed the options API and I found other two possible ideas:

2. Provide the list of tlsCipherSuites options.

import { tlsCipherSuites } from 'k6';

3. Provide a function to facilitate the stages configuration for common type of load tests:

import { soak, spike, stress } from 'k6/stages';

// for soak tests 
export let options = {
    stages: spike(100, '5m')
};

// for spike tests 
export let options = {
    stages: spike(100, '5m')
};

// for stress tests 
export let options = {
    stages: stress(100, '5m')
};

Note: I was considering these to be pure JS modules.

Thoughts?

[na--]

I like it, thanks for the issue! I also wanted to create some JS helpers for building the new execution schedulers configuration, so that can fall under this issue as well. As you can see in the simple example here, they would be quite finicky to configure with pure JSON/untyped JS objects... Though I still haven't decided what the best UX there will be, I imagine some JS config-builder functions and/or predefined JS objects will be very helpful to users...

I'm not sure all of these should be pure JS, but likely most of them shouldn't involve Go code at all, for increased flexibility and better UX. To me it seems like the only thing from these we should handle on the Go side are the constants, like the tlsCipherSuites. By exporting all of them from the Go side, there wouldn't be a chance we'd forget to update the list in the JS lib when we update the Go code.

Regarding load zones and LoadImpact-specific settings - I'd be fine if we bundled them in k6. But I'm not sure how frequently we change them, so we might also offer them as a js file in a github repo (either k6 or a new dedicated one) and import it like this even now:

import { loadZones } from "github.com/loadimpact/cloud/helper.js";
// or even something like import loadimpact from "github.com/loadimpact/cloud/helper.js"

export let options = {
    ext: {
        loadimpact: {
            name: "Hello k6 cloud!",
            distribution: {
                scenarioLabel1: { loadZone: loadZones.ashburn, percent: 50 },
                scenarioLabel2: { loadZone: loadZones.dublin, percent: 50 }
            }
        }
    }
};

And finally, this issue is somewhat connected with #929

[mstoykov]

I am more inclined toward things like this to be js files that we host in github (or some other place) that you can just import as you have shown.
This can than be used by others or us for other things as well, such as #239 and implementing all kind of helper functionality that doesn't need golang's speed

[ppcano]

I am more inclined toward things like this to be js files

Remote` modules are good for me. As far as we provide the proper instructions, the different options are valid.

I have written some comments about remote modules at #778 (comment)

For the future, when the new module resolution lands, the JS modules could be located in an additional repo and check if Babel can transform the module namespace 

https://www.npmjs.com/package/babel-plugin-transform-imports
/

[oleiade]

We believe this is an outdated issue and will close it.