Problem
k6 records which built-in modules a test uses but deliberately excludes extensions, so we have no visibility into which extensions people actually run. With binary provisioning now GA and a public catalog of official and community extensions, that blind spot blocks decisions about which extensions to support, promote, or retire. Cloud-executed runs are partly tracked, but local execution, which is most OSS usage, stays invisible.
Significance
Extension adoption has become a core product signal: it tells us which community extensions deserve promotion to official, where to spend maintenance effort, and how well binary provisioning is being adopted versus custom builds. Today product, the k6 engine team, and extension maintainers all make those calls on guesswork. The catalog's value depends on knowing what its users actually reach for, and right now we are guessing.
Cost of inaction
We keep promoting and deprecating extensions blind, spending effort on unused ones while missing popular community extensions that should become official. Every release we ship without this loses adoption history we can never recover. The decisions the catalog exists to support stay anecdote-driven.
Desired state
Anyone can see which catalog extensions are used, at what version, and through which surface they were used (an imported module, an output, or a subcommand) for both local and cloud runs, regardless of whether the binary was built with xk6 or produced by binary provisioning. The data rides the existing anonymous usage report, so users keep one familiar opt-out and have nothing new to configure. Private and unlisted extensions are never reported, only the ones already public in the catalog, so the long-standing privacy concern that kept extensions out of telemetry stays addressed.
Done when
- A used catalog importable extension (e.g.
k6/x/sql) appears in the report with module, version, and kind: js.
- A used catalog subcommand (e.g.
k6 x docs) is reported with kind: subcommand.
- A used catalog output extension (an
xk6-output-* via --out) is reported with kind: output; built-in outputs like json are not. The public catalog doesn't list output extensions (no report until added to the catalog).
- Multiple extensions used in one run are each reported.
- Network or catalog failure never fails or delays the run: with a warm catalog cache a cataloged extension is still reported; with no cache, nothing is reported (fail closed).
--no-usage-report / K6_NO_USAGE_REPORT suppresses all of it (run and subcommand paths); there is no separate opt-out.- Built-in
modules and outputs reporting is unchanged.
- A private, unlisted, or unknown extension is never reported, even when used.
- An extension baked into the binary but not used in the run is not reported.
- Reporting is identical for an xk6-built binary and a binary-provisioning-built binary.
Out of scope
- Populating the catalog with output extensions.
- Counting unique users or installations (telemetry issue).
- Telling apart xk6 builds from binary provisioning (#6111).
Related
Problem
k6 records which built-in modules a test uses but deliberately excludes extensions, so we have no visibility into which extensions people actually run. With binary provisioning now GA and a public catalog of official and community extensions, that blind spot blocks decisions about which extensions to support, promote, or retire. Cloud-executed runs are partly tracked, but local execution, which is most OSS usage, stays invisible.
Significance
Extension adoption has become a core product signal: it tells us which community extensions deserve promotion to official, where to spend maintenance effort, and how well binary provisioning is being adopted versus custom builds. Today product, the k6 engine team, and extension maintainers all make those calls on guesswork. The catalog's value depends on knowing what its users actually reach for, and right now we are guessing.
Cost of inaction
We keep promoting and deprecating extensions blind, spending effort on unused ones while missing popular community extensions that should become official. Every release we ship without this loses adoption history we can never recover. The decisions the catalog exists to support stay anecdote-driven.
Desired state
Anyone can see which catalog extensions are used, at what version, and through which surface they were used (an imported module, an output, or a subcommand) for both local and cloud runs, regardless of whether the binary was built with xk6 or produced by binary provisioning. The data rides the existing anonymous usage report, so users keep one familiar opt-out and have nothing new to configure. Private and unlisted extensions are never reported, only the ones already public in the catalog, so the long-standing privacy concern that kept extensions out of telemetry stays addressed.
Done when
k6/x/sql) appears in the report with module, version, andkind: js.k6 x docs) is reported withkind: subcommand.xk6-output-*via--out) is reported withkind: output; built-in outputs likejsonare not. The public catalog doesn't list output extensions (no report until added to the catalog).--no-usage-report/K6_NO_USAGE_REPORTsuppresses all of it (run and subcommand paths); there is no separate opt-out.modulesandoutputsreporting is unchanged.Out of scope
Related