Standartize what open
, k6/experimental/fs.open
and k6/net/grpc.Client#load
are relative to
#3857
Labels
breaking change
for PRs that need to be mentioned in the breaking changes section of the release notes
What?
Have
open
,k6/experimental/fs.open
andk6/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
andk6/net/grpc.Client#load
are relative to the entry point ofk6
- so either the folder of the argument torun
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 howrequire
(previously buggy) is defined, and also howimport
s 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
main.js:
A.js
B.js
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 opensThat 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 #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
#2674
#2782
#3534
The text was updated successfully, but these errors were encountered: