FriendsOfShopware / shopware-cli

CLI for Shopware Account and Shopware 6
MIT License
81 stars 32 forks source link

fix(deps): bump the all group with 3 updates #327

Closed dependabot[bot] closed 7 months ago

dependabot[bot] commented 7 months ago

Bumps the all group with 3 updates: github.com/evanw/esbuild, github.com/sashabaranov/go-openai and github.com/tetratelabs/wazero.

Updates github.com/evanw/esbuild from 0.20.1 to 0.20.2

Release notes

Sourced from github.com/evanw/esbuild's releases.

v0.20.2

  • Support TypeScript experimental decorators on abstract class fields (#3684)

    With this release, you can now use TypeScript experimental decorators on abstract class fields. This was silently compiled incorrectly in esbuild 0.19.7 and below, and was an error from esbuild 0.19.8 to esbuild 0.20.1. Code such as the following should now work correctly:

    // Original code
    const log = (x: any, y: string) => console.log(y)
    abstract class Foo { @log abstract foo: string }
    new class extends Foo { foo = '' }
    

    // Old output (with --loader=ts --tsconfig-raw={"compilerOptions":{"experimentalDecorators":true}}) const log = (x, y) => console.log(y); class Foo { } new class extends Foo { foo = ""; }();

    // New output (with --loader=ts --tsconfig-raw={"compilerOptions":{"experimentalDecorators":true}}) const log = (x, y) => console.log(y); class Foo { } __decorateClass([ log ], Foo.prototype, "foo", 2); new class extends Foo { foo = ""; }();

  • JSON loader now preserves __proto__ properties (#3700)

    Copying JSON source code into a JavaScript file will change its meaning if a JSON object contains the __proto__ key. A literal __proto__ property in a JavaScript object literal sets the prototype of the object instead of adding a property named __proto__, while a literal __proto__ property in a JSON object literal just adds a property named __proto__. With this release, esbuild will now work around this problem by converting JSON to JavaScript with a computed property key in this case:

    // Original code
    import data from 'data:application/json,{"__proto__":{"fail":true}}'
    if (Object.getPrototypeOf(data)?.fail) throw 'fail'
    

    // Old output (with --bundle) (() => { // <data:application/json,{"proto":{"fail":true}}> var json_proto_fail_true_default = { proto: { fail: true } };

    // entry.js if (Object.getPrototypeOf(json_proto_fail_true_default)?.fail) throw "fail"; })();

... (truncated)

Changelog

Sourced from github.com/evanw/esbuild's changelog.

0.20.2

  • Support TypeScript experimental decorators on abstract class fields (#3684)

    With this release, you can now use TypeScript experimental decorators on abstract class fields. This was silently compiled incorrectly in esbuild 0.19.7 and below, and was an error from esbuild 0.19.8 to esbuild 0.20.1. Code such as the following should now work correctly:

    // Original code
    const log = (x: any, y: string) => console.log(y)
    abstract class Foo { @log abstract foo: string }
    new class extends Foo { foo = '' }
    

    // Old output (with --loader=ts --tsconfig-raw={&quot;compilerOptions&quot;:{&quot;experimentalDecorators&quot;:true}}) const log = (x, y) => console.log(y); class Foo { } new class extends Foo { foo = ""; }();

    // New output (with --loader=ts --tsconfig-raw={&quot;compilerOptions&quot;:{&quot;experimentalDecorators&quot;:true}}) const log = (x, y) => console.log(y); class Foo { } __decorateClass([ log ], Foo.prototype, "foo", 2); new class extends Foo { foo = ""; }();

  • JSON loader now preserves __proto__ properties (#3700)

    Copying JSON source code into a JavaScript file will change its meaning if a JSON object contains the __proto__ key. A literal __proto__ property in a JavaScript object literal sets the prototype of the object instead of adding a property named __proto__, while a literal __proto__ property in a JSON object literal just adds a property named __proto__. With this release, esbuild will now work around this problem by converting JSON to JavaScript with a computed property key in this case:

    // Original code
    import data from 'data:application/json,{"__proto__":{"fail":true}}'
    if (Object.getPrototypeOf(data)?.fail) throw 'fail'
    

    // Old output (with --bundle) (() => { // <data:application/json,{"proto":{"fail":true}}> var json_proto_fail_true_default = { proto: { fail: true } };

    // entry.js if (Object.getPrototypeOf(json_proto_fail_true_default)?.fail) throw "fail"; })();

... (truncated)

Commits


Updates github.com/sashabaranov/go-openai from 1.20.3 to 1.20.4

Release notes

Sourced from github.com/sashabaranov/go-openai's releases.

v1.20.4

What's Changed

Full Changelog: https://github.com/sashabaranov/go-openai/compare/v1.20.3...v1.20.4

Commits


Updates github.com/tetratelabs/wazero from 1.6.0 to 1.7.0

Release notes

Sourced from github.com/tetratelabs/wazero's releases.

v1.7.0

Welcome to wazero 1.7: the release that upgrades like a minor, but feels like a major!

It's finally time for the long-awaited, final release of our brand new optimizing compiler. This is such a big deal that we are celebrating it at [Wasm I/O 2024][wasmio] with another round of wonderful lightning talks from wazero users [like we did in 2023][wazero1]. In fact, even this release is being tagged during the event! Stay tuned on our usual channels to see the recording:

  • Follow the [#wazero hashtag on Twitter][twitter]
  • Join the [#wazero channel on the Gophers Slack][gophers]

wazero optimizes machine code compiled from wasm

Translating Wasm bytecode into machine code can take multiple forms. An optimizing compiler performs multiple nontrivial transformations on the input code, ultimately producing more efficient ("optimized") code.

In 1.7 we replaced our internal wasm compiler with an optimizing one. This means it is a drop-in: you don’t need to do anything to use it. If interested in compiler design, please read [the docs][wazevo-docs], contributed by @​evacchi.

As for performance improvements, we have come to expect a run-time boost ranging from 10% to even 60%, with 30-40% being the average. Notably:

  • @​ncruces' fork of [coremark][coremark] shows an improved score of 15265 vs 9591, i.e. about +60% on arm64 (Apple M1 Pro)
  • [mercari/grpc-federation][mercari] improvements between 4-10% on their Wasm extensions to the [Common Extension Language][cel]
  • [kubernetes-sigs/kube-scheduler-wasm-extension][k8s-sched] sees an average of >40% decrease on schedule lifecycle overhead
  • @​achille-roussel [contributed some numbers][achille-slack] on the Go standard library (GOOS=wasip1) showing at least 30% improvements on the syscall, compress/flate (gzip) and encoding/json packages, with peaks of 60% (especially in data throughput).

While a major improvement, we decided against calling this version 2.0. If we did, we would cause library dependency lockups due to go imports needing a ‘/v2’. We take backwards compatibility seriously, so couldn’t do that to you!

As usual, @​mathetake owns the lionshare of the contributions, with @​evacchi helping along the way, especially on the new amd64 backend. Notably, @​achille-roussel also contributed a performance improvement to the compiler (#2026) and @​ncruces helped in many ways with testing and verifying the implementation, validating (among other things) against his library [go-sqlite3][go-sqlite3].

Note: an optimizing compiler does more work, so it takes longer. Production use of wazero should always compile wasm during initialization to avoid slowing down function runtime.

Experimental: Wasm Threads Spec

The Wasm Threads spec introduces instructions to explicitly share memory between modules, and new operations for atomic memory access. Compilers may use this feature for concurrent threads of execution. For instance @​anuraaga’s [Go ports of protoc plugins][protoc] needed atomic instruction support to compile to Wasm.

1.7 concludes a long journey started with @​anuraaga's first PR #1899 and continued with @​mathetake occasionally tag-teaming, especially to support in the new compiler; @​ncruces assisted with reviewing.

You can enable Wasm Threads support by setting the corresponding flag:

     // Threads support must be enabled explicitly in addition to standard V2 features.
     cfg := wazero.NewRuntimeConfig().
           WithCoreFeatures(api.CoreFeaturesV2 | experimental.CoreFeaturesThreads)

For a usage example see features_example_test.go

Experimental: Snapshot/Restore

The Snapshot/Restore experimental feature saves the state of a wasm function and restores it later. This feature has been contributed by @​anuraaga to implement exception handling in [wasilibs/go-pgquery][go-pgquery]

You can enable snapshot/restore by setting the context flag:

</tr></table> 

... (truncated)

Commits
  • 253c034 ci: removes unnecessary matrix.include (#2155)
  • 2bbe81a wazevo(frontend): allocation free initializeCurrentBlockKnownBounds (#2154)
  • 1b3f80b ci: always use the same command to upload artifacts (#2153)
  • b4f47d9 fuzz: adds --no-trace-compares flag by default (#2152)
  • 291fdf8 wazevo: fixes accidental heap allocation in VarLengthPool.Allocate (#2151)
  • 0255886 regalloc: fast check for preferred in findOrSpillAllocatable (#2150)
  • 5760022 validation: handles edge case of unexpected else (#2148)
  • a05f23b wasi: uses the shared compilation cache in tests (#2149)
  • 9f56676 testing: removes remaining gotip usage (#2147)
  • c4532da testing: pass N, P into Run of hammer (#2146)
  • Additional commits viewable in compare view


Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore major version` will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself) - `@dependabot ignore minor version` will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself) - `@dependabot ignore ` will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself) - `@dependabot unignore ` will remove all of the ignore conditions of the specified dependency - `@dependabot unignore ` will remove the ignore condition of the specified dependency and ignore conditions