Imports relative to the project root?

Grafana k6 OSS Support
1

Hello!
I wanted to ask, is it possible somehow to mention project root?
I want to make my import statements easier to understand.
And don’t want to mention paths to modules like “…/…/…/…/common” etc
It’ll be mush prettier to make them like “project_root/common
Is it possible?

2

At this time, there is no such functionality. We may end up implementing something like that as a part of this issue, but we’ll see. AFAIK, other JS runtimes like node don’t have something like this, besides things like node_modules. You can write and expand on your use case in that github issue I linked above, or in a new one, ideally with examples.

In the mean time, you can use the following somewhat ugly workaround. If you use require instead of import, you’d be able to use string concatenation and do something like this:

var project_root = "../../../../" // or some absolute path via an env variable or something like that

var name_in_this_script = require(project_root + "common.js").exported_identifier_in_common.js_file
3

@ned maybe stupid question, but
Is this possible to create your own module like “k6” or “papaparse”, “public-api” for example, where you can store different constants, paths and enpoints (project root e.g.)?
Then it will be easy to import different values similar to
import papaparse from “papaparse”

1 Like
4

Yes, you can create your own modules, here are some details: Modules

1 Like
5

@ned
I mean modules like k6 modules, similar to this

    import http from "k6/http";
    import {group} from "k6";
    import papaparse from "papaparse";

Then to use

    import common from "common"

instead of

    import common from "../../../libs/common.js"

So there will be no need to mention a whole path to the file

6

There isn’t something like that at the moment, sorry. The k6/* modules are actually Go code that’s part of the k6 binary, just exposed as JS modules for use in scripts. You can find their code here, and we accept pull requests that are suitably universal and useful, but you can’t change them at runtime or extend them via JavaScript.

Regarding node modules, we likely won’t ever be fully able to directly import them, since most of them depend on node’s standard library. We plan to improve the resolution of module filenames though, and likely align it with node’s quite a lot. You can watch this issue for updates, since I think those changes would be sufficient for your use case.