Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Update module go.k6.io/k6 to v0.53.0 #395

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Update module go.k6.io/k6 to v0.53.0 #395

wants to merge 1 commit into from

Conversation

renovate[bot]
Copy link
Contributor

@renovate renovate bot commented Mar 25, 2024 •
edited
Loading

This PR contains the following updates:

Package Change Age Adoption Passing Confidence
go.k6.io/k6 v0.49.0 -> v0.53.0 age adoption passing confidence

Release Notes

grafana/k6 (go.k6.io/k6)

v0.53.0

Compare Source

k6 v0.53.0 is here 🎉! This release includes:

  • Native ECMAScript modules support
  • New experimental OpenTelemetry metrics output
  • Blob support in experimental websockets module
  • Consolidate cloud features and commands under k6 cloud
  • Breaking change: remove magic URL resolutions

Breaking changes

Require is now specification compliant and always resolves based on the file it is written in #​3534

The require function in k6 used to resolve identifiers based on the current "root of execution" (more on that later). In a lot of cases, that aligns with the file the require is written in or a file in the same folder, which leads to the same result. In a small subset of cases, this isn't the case.

In every other implementation, and more or less by the CommonJS specification, require should always be relative to the file it is written in.

This also aligns with how ESM and dynamic import also work. In order to align with them require now uses the same underlying implementation.

There was a warning message for the last 2 releases trying to tease out cases where that would be problematic.

"root of execution" explanation

This is very much an implementation detail that has leaked and likely a not intended one.

Whenever a file is require-ed it becomes the "root of execution", and both require and open become relative to it. Once the require finishes, the previous "root of execution" gets restored. Outside of the init context execution, the main file is the "root of execution".

Example:

Have 3 files:
main.js

const s = require("./A/a.js")
if (s() != 5) {
	throw "Bad"
}
module.exports.default = () =>{} // just for k6 to not error

/A/a.js:

module.exports = function () {
  return require("./b.js");
}

/A/b.js

module.exports = 5

In this example when require is called in /A/a.js the main.js is once again the "root of execution". If you call the function in /A/a.js just after defining it though, it will work as expected.

You can use the newly added import.meta.resolve() function if you want to create a path that is relevant to the currently calling module. That will let you call it outside of a helper class and provide the path to it. Refer to docs for more details.

ECMAScript Modules (ESM) Native Support related breaking changes

As part of the ESM native support implementation, two common broken patterns in the ecosystem became apparent.

One is arguably a developer experience improvement, and the other is a consequence of the previous implementation.

Mixing CommonJS and ESM

Previously, k6 used a transpiler (Babel) internally to transpile ESM syntax to CommonJS. That led to all code always being CommonJS, and if you had CommonJS next to it, Babel would not complain.

As k6 (or the underlying JS VM implementation) did not understand ESM in itself and that CommonJS is a 100% during execution feature, this was not easy to detect or prevent.

We added a warning in v0.52.0 to give users time for migration.

To fix this - all you need is to stick to either CommonJS or ESM within each file.

Code examples and proposed changes 
import { sleep } from "k6";

module.exports.default = func() { ...}

In the example above both ESM and CommonJS are used in the same file.

You can either replace:

module.exports.default = func() {}

With the ESM syntax:

export default func() {}

Or replace:

import { sleep } from "k6";

With CommonJS:

const sleep = require("k6").sleep;
Imported identifier that can't be resolved are now errors

Previous to this, if you were using the ESM syntax and imported the foo identifier, but the exporting file didn't export it, there wouldn't be an error.

bar.js:

export const notfoo = 5;

main.js

import { foo } from "./bar.js"
export default function () {
    foo.bar(); // throws exception here
}

The example would not error out, but when it is accessed, there would be an exception as foo would be undefined.

With native ESM support, that is an error as defined by the specification and will occur sooner.

This arguably improves UX/DX, but we have reports that some users have imports like this but do not use them. So, they wouldn't be getting exceptions, but they would now get errors.

The solution, in this case, is to stop importing the not exported identifiers.

No more "magic" URL resolution

For a long time, k6 has supported special magic URLs that aren't really that.

Those were URLs without a scheme that:

  1. Started with github.com, and if pasted to a browser won't open to a file. Their appeal was that you can more easily write them by hand if you know the path within a GitHub repo.
  2. Started with cdnjs.com, and if pasted to a browser will open a web page with all the versions of the library. The appeal here is that you will get the latest version.

Both of them had problems though.

The GitHub ones seemed to have never been used by users, likely because you need to guess what the path should look like, and you can always just go get a real URL to the raw file.

While the cdnjs ones have some more usage, they are both a lot more complicated to support, as they require multiple requests to figure out what needs to be loaded. They also change over time. In addition the only known use at the moment is based on a very old example from an issue and it is even pointing to concrete, old version, of a library.

Given that this can be done with a normal URL, we have decided to drop support for this and have warned users for the last couple of versions.

Deprecated k6/experimental/tracing in favor of a JavaScript implementation

k6/experimental/tracing is arguably not very well named, and there is a good chance we would like to use the name for actual trace and span support within k6 in the future.

On top of that it can now be fully supported in js code, which is why http-instrumentation-tempo
 was created.

The JavaScript implementation is a drop-in replacement, so all you need to do is replace k6/experimental/tracing with https://jslib.k6.io/http-instrumentation-tempo/1.0.0/index.js.

The module is planned to be removed in v0.55.0, planned for November 11th, 2024.

Experimental websockets now require binaryType to be set to receive binary messages

As part of the stabilization of the k6/experimental/websockets we need to move the default value of binaryType to blob. It was previously arraybuffer and since the last version there was a warning that it needs to be set in order for binary messages to be received.

That warning is now an error.

In the future we will move the default value to blob and remove the error.

New features

The new features include:

  • Native ESM support, which also brings some quality of life JavaScript features
  • Blob support in the experimental websockets module
  • Experimental OpenTelemetry metrics output
  • Consolidating cloud related commands and features under k6 cloud
Native ESM support #​3456

With this feature k6 is now ES6+ compliant natively. Which means (asterisk free) support for the spread operator with object, private class fields and optional chaining

But also faster startup times, more consistent errors and easier addition of features as we now only need to add them to Sobek instead of also them being supported in the internal Babel.

History of compatibility mode and ECMAScript specification compliance

Some history: More than 6 years ago k6 started using core-js and babel to get ES6+ features. core-js is a implementation of a lot of the types and their features such as String.prototype.matchAll among other things, and Babel gets one piece of code that uses some syntax and returns a piece of code doing the same thing (mostly) but with different syntax. Usually with the idea of supporting newer syntax but returning code that can run on runtimes which only support old syntax.

This is great, but it means that:

  1. For core-js each VU needs to run a bunch of JS code each initialization so it can polyfill everything that is missing
  2. Babel needs to be parsed and loaded and then given files to transpile on each start.

Both of those aren't that big problems usually, but the runtime k6 uses is fairly fast, but isn't V8. What it lacks in speed it gets back in being easy to interact with from Go, the language k6 is written in.

But it means that now on each start it needs to do a bunch of work that adds up.

So long time ago for people who would want to not have to do this we added compatibility-mode=base. This allowed you to potentially not use this features and get a big speedup. Or use them outside of k6 and likely still get significant speed up if you cut down on it.

At the same time the author and maintainer of the JS runtime we used (goja) did implement a big portion of what we were missing from core-js and also Babel. After some experiments to cut down the core-js we import we ended up contributing back the remaining parts and dropping the whole library. Which lead to 5 times reduction of memory per VU for simple scripts. And even for fairly complicated ones.

With this in mind we did try to cut down Babel as well and contribute back the simpler things it was used for. This over the years lead to small pieces of what Babel did being moved to goja and then disabled in Babel. Some of those were just easy wins, some of those were things that had very bad pathological cases where using a particular syntax made transpilation times explode.

In all of that work there always were small (or not so small) breaking changes due to many factors - sometimes our new implementation was slightly wrong and we needed to fix, sometimes more than what was in the standard was enabled in core-js or Babel, sometimes the standard changed on those. And sometimes the implementation in Babel or core-js wasn't as full and didn't account for all corner cases.

ECMAScript Modules(ESM) is the last such feature that Babel was used for. It also happens to be likely the one most people used, due to the fact that it is the standard way to reuse code and import libraries.

While the work on this feature started over 2 years ago, it both depended on other features that weren't there yet, but also interacts with more or less every other feature that is part of the ECMAScript standard.

Along the way there were many internal refactors as well as additional tests to make certain we can be as backwards compatible as possible. But there also ended up being things that just weren't going to be compatible, like the listed breaking changes.

After ESM now being natively supported, compatibility-mode base vs extended has only 1 feature difference - aliasing global to globalThis to make it a bit more compatible with (old) Node.js. There is ongoing discussion if that as well should be removed.

For the purposes of having less intrusive changes and shipping this earlier a few things have not been implemented in k6. That includes top-level-await and dynamic import support. Both of them are likely to land in the next version.

import.meta.resolve() gets an URL from a relative path the same way import or require does #​3873

As part of the move to ESM a lot of cases where k6 currently do not resolve the same relative path to the same file were found. Some of those were fixed - as those in require, but others haven't.

It also became apparent some users do use the relativity of require, but also open. As we move to make this consistent among uses, we decided to let users have a better transition path forward.

Using import.meta.resolve will give you just a new URL that can be used in all functions and it will give you the same result.

import.meta.resolve uses the same algorithm and relativity as ESM import syntax. Refer to docs for more details.

Blob support in the experimental websockets module grafana/xk6-websockets#74

In order to support the default WebSocket.binaryType type as per spec ("blob"), we have added support for the Blob interface as part of the features included in the xk6-websockets module.

So, from now on it can be used with import { Blob } from "k6/experimental/websockets";. In the future, apart from graduating this module to stable, we might also want to expose the Blob interface globally (no imports will be required). But for now, please remind that its support is still experimental, as the entire module is. Refer to the docs for more details.

Experimental OpenTelemetry Output #​3834

This release introduces a new experimental output for OpenTelemetry. This allows users to send k6 metrics to any OpenTelemetry-compatible backends. More details and usage examples can be found in the documentation.

To output metrics to OpenTelemetry, use the experimental-opentelemetry output option:

 k6 run -o experimental-opentelemetry examples/script.js

If you have any feedback or issues, please let us know directly in the extension repository.

Consolidating cloud features under k6 cloud #​3813

This release introduces the first iteration of the revamped cloud-related commands under the k6 cloud command, featuring two new subcommands:

  • k6 cloud login: replaces k6 login cloud for authenticating with the cloud service. It supports token-based authentication only. The previous authentication method using email and password will still be available through the legacy k6 login cloud command, which is now deprecated and will be removed in a future release (no removal date set yet).

  • k6 cloud run: is the new official way to run k6 on the cloud service, serving as an alternative to the existing k6 cloud command. The k6 cloud command will remain available for a few more versions but will eventually function only as a wrapper for all cloud-related commands, without any direct functionality.

UX improvements and enhancements

Bug fixes

Maintenance and internal improvements

Roadmap

Future breaking changes
Experimental browser module removal

In the previous release, the browser module graduated from experimental to stable. The k6/experimental/browser module will be removed in v0.54.0. To keep your scripts working you need to migrate to the k6/browser module.

Experimental timers module removal

The experimental timers module has been deprecated for a few versions. It both has a stable import path k6/timers, but also all of it's current exports are available globally.

In the next version v0.54.0 the experimental timers module will be removed.

Experimental tracing module removal

The experimental tracing module is deprecated in this version. In two versions(v0.55.0) the experimental module will be removed.

To keep your scripts working you need to migrate to http-instrumentation-tempo jslib.

StatsD removal

In this release, we also fixed the version where we will remove the StatsD output. The StatsD output is going to be removed in the v0.55.0 release. If you are using the StatsD output, please consider migrating to the extension LeonAdato/xk6-output-statsd.

Potentially dropping global from extended compatibility-mode

Currently global is aliased to globalThis when extended compatibility-mode is used. This is currently the only difference with the base compatibility-mode.

Given that this seems to have very low usage it might be dropped in the future. See the issue for more info or if you want to comment on this.

v0.52.0

Compare Source

k6 v0.52.0 is here 🎉! Some special mentions included in this release:

Breaking changes

Switch goja to our own fork named sobek #​3775

To accelerate the development speed and bring ECMAScript Modules (ESM) support to k6 earlier (https://github.com/grafana/k6/issues/3265),
we have decided to create a fork of the goja project under the Grafana GitHub organization,
named sobek.

Starting on this release, k6 (and its extensions) now use sobek instead of the original goja, for all (of the
publicly exposed parts of the API) except for a couple of packages that are only used internally by k6.

All k6 extensions linked in the docs have had a PR for this transition opened, as explained in this comment. Any extension author who hasn't gotten a PR can follow the same steps.

Find further details in #​3772 and #​3773.

Panics are no longer being captured #​3777

Since this release, Go panics are no longer being captured by k6. This means that if a panic occurs while running a test,
the k6 process will crash, and the panic stack trace will be printed to the console.

We decided to change this behavior because it's something that was left from the past as a safeguard, but it's not as
good as it might seem. For most cases with multiple goroutines/async, it's not enough and also makes a bunch of potential
bugs seem like less of an issue.

Thus, this will help us to identify and fix bugs earlier, improve the overall stability of k6, and
most likely make the experience of developing k6 extensions friendlier.

lib.State no longer has Group #​3750

As the result of refactoring the implementation of group and check methods, in order to decouple them, and thus
enable other future improvements, the lib.State object no longer has a Group field.

This change should not affect most users, except for a couple of extensions, for which the use of Group was
already questionable:

  • xk6-fasthttp
  • xk6-g0
Other breaking changes
  • #​3797 starts using - as a special value for --archive-out to output the archive to stdout.
  • browser#1318 makes the Mouse.up and Mouse.down methods no longer take x and y coordinates. Instead, they dispatch events on the current mouse position.

New features

Experimental support for TypeScript and ES6+ using esbuild #​3738

This release of k6 introduces experimental support for TypeScript and ES6+ using esbuild, thanks to a new
compatibility mode named experimental_enhanced.

k6 run --compatibility-mode=experimental_enhanced script.js

With this new compatibility mode, the test source code is transformed using esbuild instead of Babel, which also means
that source files with the extension ".ts" are loaded by esbuild's TypeScript loader, which results in partial
TypeScript support: it removes the type information but doesn't provide type safety.

k6/browser has graduated from an experimental module #​3793

The browser module is now available as k6/browser instead of k6/experimental/browser. The previous k6/experimental/browser module will be removed on September 23rd, 2024. Refer to the migration guide for more information on how to update your scripts.

k6/browser has now a fully Async API browser#428

This release introduces a fully Async API for the k6/browser module. This means that nearly all the methods in the module now return promises. This change is part of the ongoing effort to make the browser module more user-friendly and easier to use. Please see the browser documentation for more information on how to use the new Async API.

Related Changes:

UX improvements and enhancements

  • #​3740 enables k6 extensions to initialize ReadableStream objects from Go code (io.Reader).
  • #​3798 adjusts a severity level of a log message from warn to debug for cases when k6 can't detect the terminal's size.
  • #​3797 makes it possible to output the archive to stdout by using - as the --archive-out. Thanks to @​roobre! 🙇 🎉
  • browser#1370 makes the GetAttribute method now return false when the attribute is missing, making it easier to check for the presence of an attribute.
  • browser#1371 makes the TextContent method now return false when the element's text content cannot be grabbed (like a JS document), making it easier to check for the presence of text content.
  • browser#1376 makes Request.headerValue and Response.headerValue to be case-insensitive.
  • browser#1368 enhances await usage in Javascript examples.
  • browser#1326 adds forgotten BrowserContext.browser and Page.context mappings.
  • browser#1360, browser#1327, browser#1335, browser#1365, browser#1313, browser#1322, browser#1330, browser#1343, browser#1345, browser#1352 turns the Browser, BrowserContext, ElementHandle, JSHandle, Keyboard, Mouse, Locator, and Page types' panics into errors for stability and better error handling.

Bug fixes

  • #​3774 fixes a require warning for those tests using the stdin.
  • #​3776 fixes a panic caused by passing an undefined handler to timers.
  • #​3779 fixes a panic caused by registering an undefined handler in gRPC streams.
  • xk6-websockets#73 fixes a panic caused by registering an undefined handler in WebSockets.
  • browser#1369 improves valueFromRemoteObject null detection by returning a Go nil instead of "null" as a string.
  • browser#1386 correctly handles empty string flags that don't have a value.
  • browser#1380 ensures that JSHandle.evaluate and JSHandle.evaluateHandle both set themselves as the first argument.
  • browser#1346 fixes an IFrame panic ("we either navigate top level or have old version of the navigated frame") that happens during navigation.
  • browser#1349, browser#1354 fixes Request mappings.
  • browser#1334 fixes an issue where clicking on a link that opens a new tab never navigates to the href link.
  • browser#1318 fixes the Mouse.move to correctly dispatch a down event.
  • browser#1301 fixes an error that occurs when working with a second tab and navigating to a URL.
  • browser#1387 fixes a panic when the new document or request is missing.

Maintenance and internal improvements

  • #​3752, #​3767, #​3770, #​3780, #​3782, #​3795 updates several dependencies.
  • #​3786, #​3787, #​3788, #​3789, #​3803 updates experimental modules.
  • #​3749 stops printing goja stack traces on panics, which has been empty since a while.
  • #​3760 fixes race conditions in ramping-vus tests.
  • #​3769 removes a linter setting no longer used.
  • #​3800 adds test coverage for outputting the archive to stdout.
  • browser#1298 splits browser mappings into separate files for better organization and maintainability.
  • browser#1321 adds test helpers for async VU execution to reduce the boilerplate in the tests.
  • browser#1357 updates Group and Tag usage for the latest k6.
  • browser#1361 precalculates the browser version information to prevent I/O calls when the version and userAgent methods are called. This change allows the browser module to expose these methods as a sync API to be consistent with the Playwright's API.
  • browser#1377 uses the goja fork called sobek in the browser module.
  • browser#1373 provides sync and async APIs within the browser module for making the migration to the async API easier.

Roadmap

Native ECMAScript modules

As mentioned above, the k6 team has forked goja into sobek and is currently working on native ECMAScript modules support. The current work in progress can be found in this PR and any feedback is welcome.

As part of that there likely will be some breaking changes due to the current not native support allowing stuff that shouldn't work. Like for example mixing CommonJS and ESM in the same file. Which is for example why we have added a warning that it won't work.

Support across multiple files is also not standard but due to amount of users that seems to be mixing them across files a lot of work has been done to support it. It is still likely that in the future warnings and potentially at some point future breaking changes will be enacted.

OpenTelemetry metrics output

We're also happy to share that this release cycle, we've been working on xk6-output-opentelemetry, a k6 output extension that allows you to send k6 metrics to OpenTelemetry-compatible backends. We're looking for feedback from the community. If you're interested, please try it and let us know via the extension repository!

Depending on the feedback, we plan to include this extension as an experimental output in the next k6 release.

v0.51.0

Compare Source

k6 v0.51.0 is here 🎉! Some special mentions included in this release:

Breaking changes

Transition browser APIs to Async

In the last release notes we mentioned this breaking change, and we wanted to remind and update you on the plan. In the next release (v0.52.0), most of the synchronous browser APIs will be migrated to be asynchronous (promisifying them). We expect this will affect most if not all of our users.

This breaking change will require you to add await in front of most of the browser module APIs. Without this await you will witness undocumented and unknown behavior during the runtime. To make the migration simpler we advise that you work with the latest k6 type definitions.

You can find a list of all the APIs that we expect to convert to async in a comment in issue browser#428.

Awaiting on something that’s not a thenable just returns that value, which means you can add the await keyword today on the APIs that will become async to future proof your test scripts.

Here are the reasons for making this large breaking change:

  1. Most browser APIs use some form of long-running IO operation (networking) to perform the requested action on the web browser against the website under test. We need to avoid blocking JavaScript's runtime event loop for such operations.
  2. We're going to add more asynchronous event-based APIs (such as page.on) that our current synchronous APIs would block.
  3. To align with how developers expect to work with JavaScript APIs.
  4. To have better compatibility with Playwright.

As a starting point, we have migrated a single API (the tap method), which you can find the details below that will help visualize the upcoming breaking changes.

Browser Tap is now an async method grafana/xk6-browser#1268

This release converts the Tap method in the browser module into an asynchronous method. This change is necessary to ensure that the method can be used in async contexts and to align with the rest of the browser module's planned asynchronous API. To use the Tap method, you must now add the await keyword before the method call.

Affected components:

See the following example for how to use the Tap method after this change:

Before:

import browser from 'k6/experimental/browser'

// ...

export default function () {
	// ...
	page.tap(selector, { modifiers: ["Alt", "Control", "Meta", "Shift"] });
	// ...
}

After:

import browser from 'k6/experimental/browser'

// ...

export default function () {
	// ...
	await page.tap(selector, { modifiers: ["Alt", "Control", "Meta", "Shift"] });
	// ...
}
k6/experimental/websockets will not default binaryType to `"arraybuffer"'

As part of the stabilization of the API it needs to become as close to the specification.

Early in the development the idea of adding Blob support as part was deemed feature creep and was dropped in favor of going with only "arraybuffer". But the specification defaults to returning binary responses as Blob - which was another thing that was changed.

While adding Blob is still on our radar, moving the default is always going to be a breaking change that we need to do to align with the specification.

For this release there is now a warning that will be printed if binaryType is not set to "arraybuffer" and a binary response is received. The warning will go away when binaryType is set to "arraybuffer".

In the next release the warning will become an error.

More info and place for discussion can be found in an this issue.

k6/experimental/grpc is no longer available #​3530

As the last step of the graduation process for the experimental gRPC module, we completely removed the module. It is now fully integrated into the stable k6/net/grpc module. So, if you haven't done this yet, replace your imports from k6/experimental/grpc to k6/net/grpc.

Deprecations

The following pull requests start the process to introduce breaking changes. They are currently starting to emit warning if their condition is hit, but they will turn to return errors in the future release.
It is recommended to use the suggested alternative, or to fix the script if you see the warning message.

  • #​3681 Use of not-compliant require expressions.
  • #​3680 Modules resolution of modules not previously seen during the initialization phase.
  • #​3676 Working directory is set to the current location when the script is provided using stdin, instead of the root folder.
  • #​3530 Automagically resolve modules from cdnjs and github "URLs".

New features

Introduction of k6/experimental/streams module #​3696

This release of k6 introduces the new k6/experimental/streams module, which partially supports the JavaScript
Streams API, focusing initially on the ReadableStream construct.

With the ReadableStream, users can define and consume data streams within k6 scripts. This is particularly useful for
efficiently handling large datasets or for processing data sequentially in a controlled flow.

Expand to see an example of stream's usage

The following example demonstrates creating and consuming a simple stream that emits numbers until it reaches a predefined limit:

import { ReadableStream } from 'k6/experimental/streams'

function numbersStream() {
    let currentNumber = 0

	return new ReadableStream({
		start(controller) {
			const fn = () => {
				if (currentNumber < 5) {
					controller.enqueue(++currentNumber)
					setTimeout(fn, 1000)
					return;
				}

				controller.close()
			}
			setTimeout(fn, 1000)
		},
	})
}

export default async function () {
	const stream = numbersStream()
	const reader = stream.getReader()

	while (true) {
		const { done, value } = await reader.read()
		if (done) break
		console.log(`received number ${value} from stream`)
	}

	console.log('we are done')
}

For more advanced examples, please head to the MDN Web Docs on the Streams API.

Limitations

Currently, users can define and consume readable streams. However, this release does not include support for byte readers
and controllers, nor does it include support the tee, pipeTo, and
pipeThrough methods of the ReadableStream object.

New features and updates of WebCrypto API support #​3714

This release brings support for asymmetric cryptography to the k6/experimental/webcrypto module. We added support of the elliptic curves algorithms ECDH (xk6-webcrypto#67) and ECDSA (xk6-webcrypto#69) algorithms along with new import/export key formats like spki and pkcs8.

One of the newly added operations is deriveBits, which allows parties to generate a unique shared secret by using shared public and non-shared private keys.

Expand to see an example of generating a shared secret for Alice and Bob. 
import { crypto } from 'k6/experimental/webcrypto';

export default async function () {
  // Generate a key pair for Alice
  const aliceKeyPair = await crypto.subtle.generateKey(
    {
      name: 'ECDH',
      namedCurve: 'P-256',
    },
    true,
    ['deriveKey', 'deriveBits']
  );

  // Generate a key pair for Bob
  const bobKeyPair = await crypto.subtle.generateKey(
    {
      name: 'ECDH',
      namedCurve: 'P-256',
    },
    true,
    ['deriveKey', 'deriveBits']
  );

  // Derive shared secret for Alice
  const aliceSharedSecret = await deriveSharedSecret(aliceKeyPair.privateKey, bobKeyPair.publicKey);

  // Derive shared secret for Bob
  const bobSharedSecret = await deriveSharedSecret(bobKeyPair.privateKey, aliceKeyPair.publicKey);

  // alice shared secret and bob shared secret should be the same
  console.log('alice shared secret: ' + printArrayBuffer(aliceSharedSecret));
  console.log('bob shared secret: ' + printArrayBuffer(bobSharedSecret));
}

async function deriveSharedSecret(privateKey, publicKey) {
  return crypto.subtle.deriveBits(
    {
      name: 'ECDH',
      public: publicKey,
    },
    privateKey,
    256
  );
}

const printArrayBuffer = (buffer) => {
  const view = new Uint8Array(buffer);
  return Array.from(view);
};

The sign and verify operations got support for ECDSA algorithm. The sign operation allows you to sign a message with a private key, while the verify operation allows you to verify the signature with a public key.

Other notable updates and fixes:

See webcrypto's module documentation for more details.

Timers globally available #​3589

setTimeout, setInterval and related clear functions have been part of the JavaScript ecosystem, probably for as long as it has existed.

In the previous releases we stabilized and made them available through k6/timers module. While the module isn't going anywhere and might get more identifiers, setTimeout is usually used without importing it. For this reason it is now globally available along clearTimeout, setInterval and clearInterval.

No code needs to be changed, but you no longer need to import k6/timers to use this functionality.

UX improvements and enhancements

Bug fixes

  • #​3708 denies access to execution.test.options from Init context.
  • #​3672 picks the correct value when SystemTags are set via the k6_SYSTEM_TAGS environment variable.
  • #​3657 fixes a panic when mappings field is empty in the provided SourceMap.
  • #​3717 returns a correct line number when an inlined SourceMap is used.
  • browser#1261 fixes dispose context canceled errors.
  • browser#1254 fixes an indefinite wait when testing websites with iframes.
  • browser#1291 fixes a panic on dispose of resources during a navigation.

Maintenance and internal improvements

  • #​3663, #​3673 updates several dependencies.
  • #​3674 updates the Go version, now k6 binary is built and tested using Go 1.22.
  • #​3688 updates the link to installation instructions for golangci-lint in the contribution guide. Thanks @​yomek33 for your contribution!
  • browser#1262 fixes a flaky test.
  • browser#1264 removes unimplemented APIs.

Future plans

Use Blob as default value for WebSocket.binaryType

As the changes in documentation mention, binaryType was by default set to arraybuffer, now instead it is "" (empty string).
In a not so remote future, instead, we expect to introduce and use Blob object.

WebCrypto graduation

WebCrypto got more features in the current release, and we expect to continue its expansion in the next iterations. Reaching a wider coverage will push WebCrypto module to being graduated as a stable module.

Streams API

In the not so distant future, we have plans to start using the Streams API in existing modules. Our first iteration being adding a .readable property to the already existing fs.File object.

Improve user experience for Cloud related commands

In the near future, we intend to reiterate on k6 cloud and related commands to create a simplified and more ergonomic user experience.

Remove experimental timers module

The k6/experimental/timers module is now part of the stable k6 API as k6/timers and via the globally available functions. The next release will make the experimental import no longer available.

v0.50.0

Compare Source

k6 v0.50.0 is here 🎉!

This release:

  • Adds support for uploading files from the browser module.
  • Introduces the options.cloud option.
  • Stabilizes the previously experimental timers module as the k6/timers module.
  • Brings JSON Web Key support to the k6/experimental/webcrypto module.

Breaking changes

  • websockets#60 allows manually setting the name tag, which also overwrites the url tag with the name value. This change makes it consistent with the logic that was implemented in k6 v0.41. Thanks, @​mkadirtan for contributing!
Browser APIs to Async

In future releases, we are going to be moving most of the synchronous browser APIs to asynchronous ones (promisifying them). We expect this will affect most of our users, so we are posting this upfront before making the change. Here are the reasons for making this large breaking change:

  1. Most browser APIs use some form of long-running IO operation (networking) to perform the requested action on the web browser against the website under test. We need to avoid blocking JavaScript's runtime event loop for such operations.
  2. We're going to add more asynchronous event-based APIs (such as page.on) that our current synchronous APIs would block.
  3. To align with how developers expect to work with JavaScript APIs.
  4. To have better compatibility with Playwright.

You can find a list of all the APIs that we expect to convert to async in a comment in issue browser#428.

Awaiting on something that’s not a thenable just returns that value, which means you can add the await keyword against APIs that will become async to future proof your test scripts.

New features

Add support for uploading files from the browser module browser#1097, browser#1244

You can now upload files using the available input forms on the website under test. The new API is setInputFiles which can be called from a page, frame or elementHandle types. It can upload one or more files encoded in the test script. To upload files from the local file system, work with the experimental fs module.

Expand to see the examples.

For the following examples, we will use the HTML file:

<html>

<body>
    <form method="POST" action="/upload" enctype="multipart/form-data">
        <input type="file" name="upl" id="upload" multiple />
        <input type="submit" value="Send" />
    </form>
</body>

</html>

Uploading a file can be achieved with the following script:

// Import the k6 encoder module.
import encoding from 'k6/encoding';
...
export default async function () {
  const page = browser.newPage();

  await page.goto(url)

  // Encode and upload some data into a plain text file called test.txt.
  page.setInputFiles('input[id="upload"]', { name: 'test.txt', mimetype: 'text/plain', buffer: encoding.b64encode('Hello World') })
  
  // Click on the submit button on the form to upload the file.
  const submitButton = page.locator('input[type="submit"]')
  await Promise.all([page.waitForNavigation(), submitButton.click()])

  page.close();
}

Uploading multiple files can be done with the use of an array:

page.setInputFiles('input[id="upload"]',
    [{ name: 'test.txt', mimetype: 'text/plain', buffer: encoding.b64encode('Hello World') },
    { name: 'test.json', mimetype: 'text/json', buffer: encoding.b64encode('{"message": "Hello World"}') }])

Thanks to @​bandorko! 🙇 🎉

Introducing options.cloud #​3348, #​3407

In this release, we introduce a new way of defining cloud options. From now on, you can use options.cloud instead of options.ext.loadimpact.

To migrate, you can move the loadimpact object to the root of the options object and rename it to cloud. For example:

export let options = {
    ext: {
        loadimpact: {
            name: "Legacy way of defining cloud options",
            projectID: 12345,
        }
    }
};

export let options = {
    cloud: {
        name: "Current way of defining cloud options",
        projectID: 12345,
    }
};

All scripts with legacy options.ext.loadimpact will continue to function as before. There's no planned sunset date for the legacy option, but we highly encourage using options.cloud going forward. For more details about cloud options, refer to Cloud options.

Timers API becomes part of the k6 core #​3587

With this release, the timers API is no longer experimental and can be imported as k6/timers instead of as k6/experimental/timers. The later will be supported until v0.52.0.

You can also contribute to the discussion on making the current timer exports globally available in #​3589, or just give it a 👍.

JSON Web Key support in k6/experimental/webcrypto module webcrypto#61

The experimental webcrypto module now supports the JSON Web Key (JWK) format, using the importKey and exportKey methods.

This allows you to import and export keys in the JWK format for the supported algorithms.

const generatedKey = await crypto.subtle.generateKey({name: "AES-CBC", length: "256"}, true, [ "encrypt", "decrypt"]);

const exportedKey = await crypto.subtle.exportKey("jwk", generatedKey);

UX improvements and enhancements

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

@CLAassistant
Copy link

CLA assistant check
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
You have signed the CLA already but the status is still pending? Let us recheck it.

@renovate renovate bot force-pushed the renovate/k6-core branch 2 times, most recently from c9bb40e to b4b1e9f Compare May 13, 2024 13:05
@renovate renovate bot changed the title Update module go.k6.io/k6 to v0.50.0 Update module go.k6.io/k6 to v0.51.0 May 13, 2024
@renovate renovate bot changed the title Update module go.k6.io/k6 to v0.51.0 Update module go.k6.io/k6 to v0.52.0 Jun 25, 2024
@renovate Renovate
Copy link
Contributor Author

renovate bot commented Jun 25, 2024 •
edited
Loading

ℹ Artifact update notice

File name: go.mod

In order to perform the update(s) described in the table above, Renovate ran the go get command, which resulted in the following additional change(s):

  • 30 additional dependencies were updated

Details:

Package Change
github.com/bufbuild/protocompile v0.7.1 -> v0.10.0
github.com/cenkalti/backoff/v4 v4.2.1 -> v4.3.0
github.com/grpc-ecosystem/grpc-gateway/v2 v2.16.0 -> v2.19.1
github.com/klauspost/compress v1.17.4 -> v1.17.9
go.opentelemetry.io/otel v1.21.0 -> v1.24.0
go.opentelemetry.io/otel/exporters/otlp/otlptrace v1.21.0 -> v1.24.0
go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc v1.21.0 -> v1.24.0
go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracehttp v1.21.0 -> v1.24.0
go.opentelemetry.io/otel/metric v1.21.0 -> v1.24.0
go.opentelemetry.io/otel/sdk v1.21.0 -> v1.24.0
go.opentelemetry.io/otel/trace v1.21.0 -> v1.24.0
go.opentelemetry.io/proto/otlp v1.0.0 -> v1.1.0
golang.org/x/mod v0.10.0 -> v0.17.0
golang.org/x/sync v0.5.0 -> v0.7.0
golang.org/x/tools v0.8.0 -> v0.21.1-0.20240508182429-e35e4ccd0d2d
google.golang.org/genproto/googleapis/api v0.0.0-20231002182017-d307bd883b97 -> v0.0.0-20240318140521-94a12d6c2237
google.golang.org/genproto/googleapis/rpc v0.0.0-20231002182017-d307bd883b97 -> v0.0.0-20240401170217-c3f982113cda
github.com/fatih/color v1.16.0 -> v1.17.0
github.com/go-logr/logr v1.3.0 -> v1.4.2
github.com/go-sourcemap/sourcemap v2.1.4-0.20211119122758-180fcef48034+incompatible -> v2.1.4+incompatible
github.com/golang/protobuf v1.5.3 -> v1.5.4
github.com/google/uuid v1.3.1 -> v1.6.0
github.com/jhump/protoreflect v1.15.4 -> v1.16.0
golang.org/x/net v0.19.0 -> v0.27.0
golang.org/x/oauth2 v0.13.0 -> v0.18.0
golang.org/x/sys v0.15.0 -> v0.22.0
golang.org/x/term v0.15.0 -> v0.22.0
golang.org/x/text v0.14.0 -> v0.16.0
google.golang.org/grpc v1.60.0 -> v1.64.1
google.golang.org/protobuf v1.31.1-0.20231027082548-f4a6c1f6e5c1 -> v1.34.2

@renovate renovate bot changed the title Update module go.k6.io/k6 to v0.52.0 Update module go.k6.io/k6 to v0.53.0 Aug 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
1 participant
@CLAassistant