Transforming libraries takes a long time

[ppcano]

Transforming a library takes a long time; making the development flow when using libraries to become unproductive.

Running k6 in verbose mode shows the following result:

import moment from "./vendor/moment.js";
DEBU[0000] Resolved...                name="/Users/ppcano/dev/li/k6-tests/vendor/moment.js"
DEBU[0229] Babel: Transformed       t=3m48.669249149s

import faker from "./vendor/faker.js";
DEBU[0001] Resolved...                      name="/Users/ppcano/dev/li/k6-tests/vendor/faker.js"
DEBU[0114] Babel: Transformed        t=1m53.851882106s

import moment from "s3.amazonaws.com/k6samples/moment.js";
DEBU[0002] Fetched!                          len=128945 t=1.22518284s url="https://s3.amazonaws.com/k6samples/moment.js?_k6=1"
DEBU[0217] Babel: Transformed         t=3m35.005278253s

[liclac]

Yeah... I wanted to give another compiler a shot, but I think we may be hitting the limit of what goja can do here. Maybe we could cache compiled scripts somehow...?

[micsjo]

Definitively cache compiled scripts. 3 minutes is already there borderline. Add a couple of them and you can quickly get 15 minutes of startup time just waiting for your 30 second test to run...

[ppcano]

@liclac Random thoughts on this issue.

I find compiled modules to work differently than other ES6 modules. A compiled module is usually a large Javascript library with a lot of functionality, and ES6 modules are often much smaller modules related to your load testing domain.

Based on the output, it looks the Babel compilation takes a lot of time when including a large library.

I have only a basic idea about goja and babel, but I wonder if k6 could avoid the babel transformation for "compiled modules" and try to load and import them differently.

[ppcano]

After a conversation with @liclac, we came to the conclusion that we could support a different API for ES5 modules.

// ES6 module
import utils from './lib/utils.js' 

// ES5 module
const moment = require('./vendor/moment.js')

require will skip the Babel transformation and it can be used to import ES5 modules like bundled Javascript libraries.

[liclac]

That's not a conclusion as much as it is one possible way to solve it. I don't like it, because it means you need to know if the file you're importing is written in ES5 or ES6.

[ppcano]

@liclac

With proper documentation, I don't find having two syntaxes for the different type of modules to be a big issue. This may not be the ideal solution, but it solves this problem at this moment. Later when we found a better way, we can deprecate the ES5 require API and migrate to imports.

[liclac]

Here's a wild idea: what if we tried parsing the file as ES5, then if there are syntax errors, we run Babel on it and try again.

[liclac]

And... it works! Anything that isn't valid ES5 is now run through Babel and retried. Negligible slowdown for ES6 sources, near-instant loading of arbitrarily large ES5 modules.

[ppcano]

@liclac 👏 🥇

Looking forward testing it

[ppcano]

@liclac I tested it, and this works perfectly.

Please, could you build a new release including this fix?

After the new release, I will upgrade the Modules doc and promote it again aiming to find new feature testers.

[ghost]

So, am I right to say k6 supports both ES5 and ES6, but ES5 will compile much faster as it wont need to go through the Babel transpiler and now is a second option?

[liclac]

No, this is purely a performance increase when loading third-party libraries. ES6 is compiled down to ES5 under the hood, but we don't support writing scripts in ES5 directly and do not guarantee API stability for anything but ES6.

[ayaka209]

Here's a wild idea: what if we tried parsing the file as ES5, then if there are syntax errors, we run Babel on it and try again.

this behavior is not mentioned in docs.
I have a browerified module, which has 60K+ lines, it takes 7m+ to transform
DEBU[0491] Babel: Transformed t=7m23.6293474s

after reading this issue, I manually transform it to es5 and got good result.