Support for node modules resolution

[ludeknovy]

Use case:
I have a package with contains all of my api calls. I use them for functional tests. But this package itself is dependent on another external package. It would be really helpful If I could reuse this package across functional and performance tests.

[robingustafsson]

Thanks @ludeknovy for creating an issue for this.

Looked a bit again at this today. I think we should aim for supporting more of node's dependency resolution algorithm then we do today (https://nodejs.org/api/modules.html#modules_all_together). We support parts of it but there are several large gaps. We won't support all of the steps since they don't make sense outside of node but we can definitely expand to cover more parts of it.

[san-slysz]

I agree. I faced the same issue. Here's the 2 aspects I mainly lack:

• being able to use path/module instead of path/index.js (not having to explicite index)
• being able to use path/module/file instead of path/module/file.js (not having to explicite extension)

Hopefully this will naturally come with the feature :).

[na--]

Some docs that have to be reviewed before we proceed with this:

• https://github.com/nodejs/modules/blob/master/doc/plan-for-new-modules-implementation.md
• http://2ality.com/2018/12/nodejs-esm-phases.html (HN discussion)

[na--]

I am closing this, since it's very unlikely for k6 to ever support the old node module resolution algorithm. As shown in the links above, NodeJS themselves are getting rid of it with their new modules support. And if anyone wants it, it's very easy to setup a webpack pipeline to resolve and bundle old-node-style modules like this: https://github.com/k6io/template-es6

It even has the added bonus of easily being able to transform the scripts with Babel in the same pipeline, making them suitable for k6's base compatibility mode and benefiting from the resulting improved performance.