-
Notifications
You must be signed in to change notification settings - Fork 1.5k
Description
k6 currently uses three different import patterns depending on whether the user is importing a built-in module, a compiled extension, or a remote JavaScript library. This fragmented system introduces unnecessary complexity, requiring users to understand k6’s internal architecture before they can effectively use the ecosystem of extensions and libraries.
Why this matters
This inconsistency increases the cognitive load on users, especially newcomers, by making the learning curve steeper than necessary. It slows down test development, impairs discoverability of available tools, and makes extension usage feel unintuitive. A more cohesive and simplified import experience would remove friction, enhance developer satisfaction, and help accelerate adoption of k6 across the broader developer and testing community.
What we want to build
We propose a unified import resolver for k6 that allows users to import any resource—whether a built-in module, Go-based extension, or remote JavaScript library—using a single, standardized URI-style syntax. All first-party resources would live under a common grafana: namespace, while custom namespaces could be defined for third-party and enterprise use. The system would also support versioning through pragma-based constraints to maintain compatibility and clarity.
What success looks like
- k6 users can import any type of extension using one consistent and intuitive syntax.
- The learning curve for using and discovering k6 extensions is significantly reduced.
- Developers are empowered to manage and use their own namespaces, unlocking more enterprise and custom use cases.
- Extension usage increases across the community, and the k6 ecosystem grows with minimal support overhead.