Open renovate[bot] opened 5 months ago
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.
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):
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 |
This PR contains the following updates:
v0.49.0
->v0.53.0
Release Notes
grafana/k6 (go.k6.io/k6)
### [`v0.53.0`](https://redirect.github.com/grafana/k6/releases/tag/v0.53.0) [Compare Source](https://redirect.github.com/grafana/k6/compare/v0.52.0...v0.53.0) 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](https://redirect.github.com/grafana/k6/issues/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 ```javascript const s = require("./A/a.js") if (s() != 5) { throw "Bad" } module.exports.default = () =>{} // just for k6 to not error ``` /A/a.js: ```javascript module.exports = function () { return require("./b.js"); } ``` /A/b.js ```javascript 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.Code examples and proposed changes
```javascript 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: ```javascript module.exports.default = func() {} ``` With the ESM syntax: ```javascript export default func() {} ``` Or replace: ```javascript import { sleep } from "k6"; ``` With CommonJS: ```javascript const sleep = require("k6").sleep; ```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`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/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](https://redirect.github.com/grafana/k6/pull/1206). 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.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: ```javascript 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') } ```Expand to see an example of generating a shared secret for Alice and Bob.
```javascript 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); }; ```Expand to see the examples.
For the following examples, we will use the HTML file: ```html ``` Uploading a file can be achieved with the following script: ```js // 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: ```js 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"}') }]) ```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.
This PR was generated by Mend Renovate. View the repository job log.