Background

The functionality of k6 can be extended using various extensions, such as JavaScript and Output extensions. There's a recognized need to support auxiliary activities that occur before or after k6 test runs. These activities could range from setting up output extensions (e.g., creating a database) to post-processing exported metrics, or even providing mock servers for JavaScript extensions to aid in test writing.

Integrating these auxiliary activities as k6 subcommands would significantly simplify their distribution and use, as well as facilitate the modularization of k6 itself.

Goals

Auxiliary activities related to k6 tests should be implementable as extensions built into k6.
k6 subcommands should be modularly implementable as k6 extensions (e.g., k6 cloud subcommand as an extension).

Proposal 1: Parser-dependent API (Proof of Concept)

This proposal suggests that subcommand extensions should utilize the same command parser (spf13/cobra) and flag parser (spf13/pflag) libraries as k6. The registration of a subcommand would involve registering the cobra.Command factory function that implements it. This approach aligns with how existing k6 subcommands cobra.Command structures are already generated by factory functions.

Pros:

• Optimal User Experience: Subcommands implemented as extensions would function with complete consistency with the built-in subcommands, ensuring a seamless user experience.
• Minimal Implementation Effort: This solution can be implemented with minimal development effort.

Cons:

• Third-Party Dependency: The subcommand extension API would depend on a third-party library API.
• API Change Risk: If k6 were to switch to a different CLI parser in the future, the subcommand extension API would also need to change.

Considerations:

• A CLI parser change has not been a priority for k6, and it's considered unlikely to happen in the near future.
• Should a CLI parser change occur, it would constitute an incompatible API change, which could be managed effectively if combined with a major version change of k6.

Proof of Concept (PoC) Objective

The objective of this issue is to create a Proof of Concept for Proposal 1: Parser-dependent API. The PoC should demonstrate the feasibility of integrating a subcommand extension that leverages spf13/cobra and spf13/pflag to ensure consistency with k6's existing CLI.

Params

The parameter of the subcommand factory function in the PoC is practically *state.GlobalState. The factory functions of the k6 internal commands also expect this type of parameter. Later, if needed, a subcommand.Params type can be created (similar to output.Params), but in the PoC, it is faster to use the existing state.GlobalState. However, state.GlobalState was created specifically for use with k6 commands, so subcommand.Params would probably be a copy of it sooner or later, so it is questionable whether it is needed.

More details

For more details, read the Design Doc: Subcommand extension(internal only) document.