Standardize `x-` namespace prefix for Output Extensions

[szkiba]

This proposal suggests establishing a standardized naming convention—specifically the x- prefix—for Output Extensions in k6.

Currently, the k6 extension ecosystem enforces namespaces for other extension types to distinguish them from core functionality:

• JS Extensions: Import paths must strictly start with k6/x/ (e.g., import ... from 'k6/x/sql').
• Subcommand Extensions: Must be invoked via the x subcommand (e.g., k6 x my-cmd).

However, Output Extensions currently share the global namespace with built-in outputs. A custom output is registered and invoked exactly like a native one (e.g., --out kafka vs --out influxdb).

Proposal

Enforce or strongly recommend that Output Extensions register their names using an x- prefix.

Example:

# Current state (Ambiguous)
k6 run --out kafka=...

# Proposed state (Explicit)
k6 run --out x-kafka=...

Motivation & Benefits

1. Consistency across the Extension Ecosystem
   Aligning Output Extensions with the existing k6/x/ (JS) and k6 x (Subcommand) patterns creates a cohesive developer experience. It makes it immediately obvious to the end-user which parts of their stack are provided by the core binary and which are provided by extensions.

2. Conflict Prevention & Future-Proofing
   Currently, if an extension registers a generic name (e.g., kafka, sql, redis) and k6 core later introduces a native output with the same name, it creates a breaking conflict. Reserving the x- namespace for extensions guarantees that community contributions will never clash with future built-in k6 outputs.

3. Enabling Automatic Extension Resolution
   This is a critical enabler for future tooling improvements. By enforcing a prefix, tools (or k6 itself) can programmatically distinguish between a typo and a missing extension.

   • Scenario A: User types --out ifluxdb (missing 'n'). The system sees no x- prefix, recognizes it as an attempt to use a core output, and errors with "Unknown output 'ifluxdb', did you mean 'influxdb'?".
   • Scenario B: User types --out x-custom-sink. The system detects the x- prefix, identifies it as an extension, and can trigger automatic extension resolution.

Without this distinction, automatic resolution logic is risky as it might attempt to resolve typos as external packages.

[szkiba]

Potential Conflict with "Unified Import Paths" (k6 Hub Concept)

This proposal raises a strategic concern regarding the "Unified Import Paths" (or k6 Hub) concept, which aims to harmonize how extensions and core modules are referenced. Strictly enforcing an x- prefix for output extensions might create a rigid boundary that conflicts with this future architecture.

The JS Extension Parallels
Currently, a JavaScript extension like xk6-faker is imported via a dedicated extension namespace:
import ... from 'k6/x/faker';

However, the future vision for the k6 Hub moves toward federated or scoped imports, where the same extension might be referenced as:
import ... from 'k6:@grafana/faker';

This evolution allows extensions to "graduate" to official support or be swapped without breaking changes to the import logic.

The Output Extension Conflict
If the x- prefix is strictly enforced for Output Extensions (e.g., requiring --out x-tsv), it solidifies a hard distinction between extensions and builtin modules.

If an extension like tsv were to be adopted into the core k6 ecosystem, users would be forced to rewrite their CLI flags and CI pipelines to remove the prefix.

Alternative Consideration:
Perhaps the naming strategy should align with the future scoped syntax rather than a generic prefix. For example, supporting scoped outputs like --out @grafana/tsv would be more consistent with the k6:@grafana/faker direction. This allows for clear ownership and namespace resolution without permanently coupling the implementation source (extension vs. core) to a "temporary" x- prefix.