Standartize what `open` , `k6/experimental/fs.open` and `k6/net/grpc.Client#load` are relative to

[mstoykov]

What?

Have open , k6/experimental/fs.open and k6/net/grpc.Client#load be relative to the same path for each execution.

Or at least specify and stick to one new norm among them and anything else related to loading files.

Why?

Consistency, ease of reasoning, also potentially debugging and using one in place of the other.

Current situation:

k6/experimental/fs.open and k6/net/grpc.Client#load are relative to the entry point of k6 - so either the folder of the argument to run or if is - (stdin) - the folder k6 is executed in.

I am pretty sure this was a mistake in gRPC (#2781). fs.open was more of "let's not make this more complicated especially given this is an experimental module".

open on the other hand is relative to the currently executed file, but I would argue by design it was supposed to be relative to the file it is called in. Similar to how require (previously buggy) is defined, and also how imports both static and dynamic usually work in ECMAScript. And how they are actually now implemented.

So for me this seems like a bug all around.

Examples of the behaviour:

If we have the following structure

/root/main.js
/path/A.JS
/path/B/B.js

main.js:

import "/path/A.JS"

A.js

import { openHelper, fsOpenHelper } from "./B/B.js";
import fs from "k6/experimental/fs";
open("./some/path/file.csv") // this is /path/some/path/file.csv - which seems pretty correct
fs.open("./some/path/file.csv") // this is /root/some/path/file.csv - which isn't the worst ... but still confusing
// same for grpc 
openHelper("./some/path/file.csv") // this is /path/some/path/file.csv - which is ... quite impossible to guess
fsOpenHelper("./some/path/file.csv") // this is /root/some/path/file.csv - at least this is consistent

B.js

import fs from "k6/experimental/fs";

export function openHelper(s) { open(s) }
export function fsOpenHelper(s) { fs.open(s) }

In this case the openHelper is arguably the "good" example for the current behaviour, but if you wanted to have helper that does something completely different but as part of it it opens

export function checkSomethingExists(id) {
    return open("./some/path/to/file.json")[id]
} 

That relative path will be relative to whatever calls checkSomethingExists as in the example above.

Proposal:

Change all of them to be relative to the file being called in - how imports and require work.

Given that the three currently have 3 different behaviours and only on of them is experimental - we will need to have at least a couple of releases with warnings about this.

I recommend we do the same as with require - test that the new implementation will not give a different result (which is possible in some cases) and only if it isn't - then emit a warning.

We can also recommend using https://github.com/grafana/k6/issues/3856 if it is implemented at the time.

The existance of import.meta.resolve doesn't change the fact that the functions having different things they are relative to is a confusing behaviour.

Related issues and PRs

https://github.com/grafana/k6/issues/2674 https://github.com/grafana/k6/pull/2782 https://github.com/grafana/k6/issues/3534