-
Notifications
You must be signed in to change notification settings - Fork 7
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.
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
Update module go.k6.io/k6 to v0.53.0 #395
base: main
Are you sure you want to change the base?
Conversation
|
9a86400
to
266f258
Compare
c9bb40e
to
b4b1e9f
Compare
b4b1e9f
to
d6b3c82
Compare
ℹ Artifact update noticeFile name: go.modIn order to perform the update(s) described in the table above, Renovate ran the
Details:
|
d6b3c82
to
a803db1
Compare
This PR contains the following updates:
v0.49.0
->v0.53.0
Release Notes
grafana/k6 (go.k6.io/k6)
v0.53.0
Compare Source
k6
v0.53.0
is here 🎉! This release includes:k6 cloud
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 therequire
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 themrequire
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 bothrequire
andopen
become relative to it. Once therequire
finishes, the previous "root of execution" gets restored. Outside of theinit
context execution, the main file is the "root of execution".Example:
Have 3 files:
main.js
/A/a.js:
/A/b.js
In this example when
require
is called in/A/a.js
themain.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
In the example above both ESM and CommonJS are used in the same file.
You can either replace:
With the ESM syntax:
Or replace:
With CommonJS:
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:
main.js
The example would not error out, but when it is accessed, there would be an exception as
foo
would beundefined
.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:
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.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 implementationk6/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
withhttps://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 messagesAs part of the stabilization of the
k6/experimental/websockets
we need to move the default value ofbinaryType
toblob
. It was previouslyarraybuffer
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:
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:
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
vsextended
has only 1 feature difference - aliasingglobal
toglobalThis
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 wayimport
orrequire
does #3873As 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 alsoopen
. 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 theBlob
interface as part of the features included in thexk6-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 theBlob
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:If you have any feedback or issues, please let us know directly in the extension repository.
Consolidating cloud features under
k6 cloud
#3813This release introduces the first iteration of the revamped cloud-related commands under the
k6 cloud
command, featuring two new subcommands:k6 cloud login
: replacesk6 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 legacyk6 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 existingk6 cloud
command. Thek6 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
BrowserContextOptions
into mapping layer.k6/experimental/timers
deprecation warning updates.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 inv0.54.0
. To keep your scripts working you need to migrate to thek6/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
fromextended
compatibility-modeCurrently
global
is aliased toglobalThis
whenextended
compatibility-mode is used. This is currently the only difference with thebase
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:goja
namedsobek
.k6/browser
has graduated from an experimental module, and now has a fully Async API.Breaking changes
Switch
goja
to our own fork namedsobek
#3775To 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 originalgoja
, for all (of thepublicly 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 hasGroup
#3750As the result of refactoring the implementation of
group
andcheck
methods, in order to decouple them, and thusenable other future improvements, the
lib.State
object no longer has aGroup
field.This change should not affect most users, except for a couple of extensions, for which the use of
Group
wasalready questionable:
xk6-fasthttp
xk6-g0
Other breaking changes
-
as a special value for--archive-out
to output the archive to stdout.Mouse.up
andMouse.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
.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 #3793The browser module is now available as
k6/browser
instead ofk6/experimental/browser
. The previousk6/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#428This 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:
Browser
,BrowserContext
,ElementHandle
,Frame
,JSHandle
,Keyboard
,Locator
,Mouse
,Page
,Request
,Response
APIs to async.UX improvements and enhancements
ReadableStream
objects from Go code (io.Reader
).warn
todebug
for cases when k6 can't detect the terminal's size.-
as the--archive-out
. Thanks to @roobre! 🙇 🎉GetAttribute
method now returnfalse
when the attribute is missing, making it easier to check for the presence of an attribute.TextContent
method now returnfalse
when the element's text content cannot be grabbed (like a JSdocument
), making it easier to check for the presence of text content.Request.headerValue
andResponse.headerValue
to be case-insensitive.await
usage in Javascript examples.BrowserContext.browser
andPage.context
mappings.Browser
,BrowserContext
,ElementHandle
,JSHandle
,Keyboard
,Mouse
,Locator
, andPage
types' panics into errors for stability and better error handling.Bug fixes
require
warning for those tests using the stdin.valueFromRemoteObject
null
detection by returning a Gonil
instead of"null"
as astring
.JSHandle.evaluate
andJSHandle.evaluateHandle
both set themselves as the first argument.Request
mappings.Mouse.move
to correctly dispatch adown
event.Maintenance and internal improvements
goja
stack traces on panics, which has been empty since a while.Group
andTag
usage for the latest k6.version
anduserAgent
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.goja
fork calledsobek
in the browser module.Roadmap
Native ECMAScript modules
As mentioned above, the k6 team has forked
goja
intosobek
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 thisawait
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:
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#1268This release converts the
Tap
method in thebrowser
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 theTap
method, you must now add theawait
keyword before the method call.Affected components:
locator.tap
page.tap
frame.tap
elementHandle.tap
See the following example for how to use the
Tap
method after this change:Before:
After:
k6/experimental/websockets
will not defaultbinaryType
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 asBlob
- 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 whenbinaryType
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 #3530As 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 fromk6/experimental/grpc
tok6/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.
require
expressions.New features
Introduction of
k6/experimental/streams
module #3696This release of k6 introduces the new
k6/experimental/streams
module, which partially supports the JavaScriptStreams API, focusing initially on the
ReadableStream
construct.With the
ReadableStream
, users can define and consume data streams within k6 scripts. This is particularly useful forefficiently 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:
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
, andpipeThrough
methods of theReadableStream
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 likespki
andpkcs8
.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.
The
sign
andverify
operations got support for ECDSA algorithm. Thesign
operation allows you to sign a message with a private key, while theverify
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 alongclearTimeout
,setInterval
andclearInterval
.No code needs to be changed, but you no longer need to import
k6/timers
to use this functionality.UX improvements and enhancements
asyncInvoke
method to thek6/net/grpc
module. It's a non-blocking version of theinvoke
method.Bug fixes
execution.test.options
from Init context.k6_SYSTEM_TAGS
environment variable.mappings
field is empty in the provided SourceMap.Maintenance and internal improvements
golangci-lint
in the contribution guide. Thanks @yomek33 for your contribution!Future plans
Use Blob as default value for WebSocket.binaryType
As the changes in documentation mention,
binaryType
was by default set toarraybuffer
, 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 ask6/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:
options.cloud
option.k6/timers
module.k6/experimental/webcrypto
module.Breaking changes
name
tag, which also overwrites theurl
tag with thename
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:
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 apage
,frame
orelementHandle
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:
Uploading a file can be achieved with the following script:
Uploading multiple files can be done with the use of an array:
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 ofoptions.ext.loadimpact
.To migrate, you can move the
loadimpact
object to the root of theoptions
object and rename it tocloud
. For example: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 usingoptions.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 ask6/experimental/timers
. The later will be supported untilv0.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#61The experimental webcrypto module now supports the JSON Web Key (JWK) format, using the
importKey
andexportKey
methods.This allows you to import and export keys in the JWK format for the supported algorithms.
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.
This PR was generated by Mend Renovate. View the repository job log.