Include non-transpiled JS files in k6 archives

[robingustafsson]

There are two reasons why this would be a good idea:

1. In our cloud service (loadimpact.com) we would like to be able to access the non-transpiled ES6 JS. The current ES5 transpiled JS file(s) included in k6 archives would not be as recognizable to the user, and we'd want to be able to show the script for user reference when analyzing results (and down the line for displaying scripting errors etc.). It could also be that the JS code is not written by the user directly but rather converted from some other format (HAR/Postman/etc) in which case we'd like to be able to show the code in various ways to guide/educate the user on scripting.

2. The k6 archive could be used to share a test with others. Not just for execution as would be the primary use case now given what's included in the archive, but for sharing the actual scripts and data files themselves. Sometimes it would be quicker to just k6 archive script.js and share over Slack or whatever than to share the code through Github or the like.

For reference this simple ES6 JS code:

import http from "k6/http";
import { sleep } from "k6";

export default function() {
  http.get("http://test.loadimpact.com");
  sleep(1);
};

gets transpiled into this ES5 code when included in the archive:

"use strict";Object.defineProperty(exports, "__esModule", { value: true });exports.default =

function () {
  _http2.default.get("http://test.loadimpact.com");
  (0, _k.sleep)(1);
};var _http = require("k6/http");var _http2 = _interopRequireDefault(_http);var _k = require("k6");function _interopRequireDefault(obj) {return obj && obj.__esModule ? obj : { default: obj };};

[liclac]

Current behaviour is actually an optimisation from the dark days before #212, but this is much more sensible.

[ppcano]

@robingustafsson

Correct me if I am wrong, but we discussed initially we only want to include the non-transpiled content of the script file: the one that contains the default test function.

Users could import local modules and libraries but this is something we are not interested in at this moment.

[robingustafsson]

@ppcano Yes, but that's just a specialized use case for the cloud service. I might be wrong, but I don't see any added complexity in including the full source to cover the more general "sharing a test" use case. @liclac Correct me if I'm wrong in my assumption.

[liclac]

A negligible difference in complexity, a big gain in consistency.