grafana
Using Unregistered Extensions
Feature Description
Proprietary extensions are usually not registered in the extension registry. Their use would be made possible by supporting the use of unregistered extensions.
Suggested Solution (optional)
New --register flag:
--register name=path use unregistered extension, where name is the name of the extension and path is the module path. It implies the use of the native builder (--builder native)
k6x --register k6/x/foo=github.com/org/foo run script.js
@szkiba
I think this will be a common case, and I'd like to avoid the need to pass CLI flags.
This could be solved by adding the path to the Pragma
use k6 with github.com/org/foo > 0.2
# or any other alternative
Two reasons why i think this is important:
(1) Better UX. I don't need to pass a CLI flag. Which is also more cumbersome because I need to know beforehand which extensions and paths to register.
(2) It makes collaboration much easier.
For example, someone wants to run a test that was created by another team. Then, they need to know which extension and paths to register.
k6 objective should be to allow running a test just like k6 run script.js == k6x run script.js. A new user of the test doesn't need to know more to run a test.
Note that I don't knowhow the package manager works internally. An alternative, something like xk6 register script.js which is kind of package_manager install.
Hi @ppcano ,Thanks for the feedback and suggestion. Your use case is absolutely valid and should be supported. My original consideration was that the source of the test should not show the knowledge of whether the given extension is registered or not. Especially since this may be a temporary state and the extension may be registered over time.
However, I understand your use case. Taking this into account, the proposed solution is modified as follows:
In the "use k6" pragma and the --with command line flag, in addition to the name of the extension, the go module should also be able to specified in the form of a name=module expression, where name is the name of the extension and module is the go module.
pragma example
"use k6 with k6/x/foo=github.com/org/foo > 0.2"
command line example
k6x run --with k6/x/foo=github.com/org/foo script.js
What do you think about this proposed solution?
@szkiba
"use k6 with k6/x/foo=github.com/org/foo > 0.2"
That solves what I mentioned above. 💯
Two questions popping up:
- How will it work with
--replace? - And then, when is the
--withthe CLI flag useful or necessary?
@ppcano In the meantime, I've been thinking too, and I'm afraid my above suggestion is a bit confusing. It is against the principle of SoC, dependency is dependency, and extension registration is extension registration :) It is not worth mixing the two. Based on this, the proposed solution is:
Introducing a new "use k6" pragma and command line flag to support the use of unregistered extensions.
register pragma
With the help of the "use k6 register" pragma, an extension registration can be specified for the duration of the test run in the following form:
"use k6 register name module"
where name is the name of the extension and module is the go module implementing the extension. For example:
"use k6 register k6/x/foo github.com/org/xk6-foo"
--register flag
The --register command line flag can be used to specify registration for unregistered extensions in the following form:
--register name=module
where name is the name of the extension and module is the go module implementing the extension. For example:
k6x --register k6/x/foo=github.com/org/xk6-foo run script.js
For your questions:
How will it work with --replace?
The register and replace features should be independent of each other. The register feature is used when assigning a module to the dependency, and the replace feature replaces the module during the build.
And then, when is the --with the CLI flag useful or necessary?
The purpose of --with is to add an extra dependency. It can be used to reduce the number of cache updates if, for example, we know in advance that certain extensions will be needed during successive test runs. Another use is to use build to prepare the k6 binary in advance without a script and later run it directly.
Just one more alternative solution:
In addition to the extension registry, support for other methods to resolve the extension name to the go module. Such a method can be the GitHub repository search based on the xk6 topics.