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.

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

chore(deps): update driver adapters directory (patch) #4775

Merged
merged 1 commit into from
Apr 3, 2024

Conversation

renovate[bot]
Copy link
Contributor

@renovate renovate bot commented Mar 16, 2024

Mend Renovate

This PR contains the following updates:

Package Change Age Adoption Passing Confidence
@types/node (source) 20.11.24 -> 20.11.30 age adoption passing confidence
esbuild 0.20.1 -> 0.20.2 age adoption passing confidence
typescript (source) 5.4.2 -> 5.4.3 age adoption passing confidence

Release Notes

evanw/esbuild (esbuild)

v0.20.2

Compare Source

  • 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";
    })();
    
    // New output (with --bundle)
    (() => {
      // <data:application/json,{"__proto__":{"fail":true}}>
      var json_proto_fail_true_default = { ["__proto__"]: { fail: true } };
    
      // example.mjs
      if (Object.getPrototypeOf(json_proto_fail_true_default)?.fail)
        throw "fail";
    })();
  • Improve dead code removal of switch statements (#​3659)

    With this release, esbuild will now remove switch statements in branches when minifying if they are known to never be evaluated:

    // Original code
    if (true) foo(); else switch (bar) { case 1: baz(); break }
    
    // Old output (with --minify)
    if(1)foo();else switch(bar){case 1:}
    
    // New output (with --minify)
    foo();
  • Empty enums should behave like an object literal (#​3657)

    TypeScript allows you to create an empty enum and add properties to it at run time. While people usually use an empty object literal for this instead of a TypeScript enum, esbuild's enum transform didn't anticipate this use case and generated undefined instead of {} for an empty enum. With this release, you can now use an empty enum to generate an empty object literal.

    // Original code
    enum Foo {}
    
    // Old output (with --loader=ts)
    var Foo = /* @&#8203;__PURE__ */ ((Foo2) => {
    })(Foo || {});
    
    // New output (with --loader=ts)
    var Foo = /* @&#8203;__PURE__ */ ((Foo2) => {
      return Foo2;
    })(Foo || {});
  • Handle Yarn Plug'n'Play edge case with tsconfig.json (#​3698)

    Previously a tsconfig.json file that extends another file in a package with an exports map failed to work when Yarn's Plug'n'Play resolution was active. This edge case should work now starting with this release.

  • Work around issues with Deno 1.31+ (#​3682)

    Version 0.20.0 of esbuild changed how the esbuild child process is run in esbuild's API for Deno. Previously it used Deno.run but that API is being removed in favor of Deno.Command. As part of this change, esbuild is now calling the new unref function on esbuild's long-lived child process, which is supposed to allow Deno to exit when your code has finished running even though the child process is still around (previously you had to explicitly call esbuild's stop() function to terminate the child process for Deno to be able to exit).

    However, this introduced a problem for Deno's testing API which now fails some tests that use esbuild with error: Promise resolution is still pending but the event loop has already resolved. It's unclear to me why this is happening. The call to unref was recommended by someone on the Deno core team, and calling Node's equivalent unref API has been working fine for esbuild in Node for a long time. It could be that I'm using it incorrectly, or that there's some reference counting and/or garbage collection bug in Deno's internals, or that Deno's unref just works differently than Node's unref. In any case, it's not good for Deno tests that use esbuild to be failing.

    In this release, I am removing the call to unref to fix this issue. This means that you will now have to call esbuild's stop() function to allow Deno to exit, just like you did before esbuild version 0.20.0 when this regression was introduced.

    Note: This regression wasn't caught earlier because Deno doesn't seem to fail tests that have outstanding setTimeout calls, which esbuild's test harness was using to enforce a maximum test runtime. Adding a setTimeout was allowing esbuild's Deno tests to succeed. So this regression doesn't necessarily apply to all people using tests in Deno.

Microsoft/TypeScript (typescript)

v5.4.3: TypeScript 5.4.3

Compare Source

For release notes, check out the release announcement.

For the complete list of fixed issues, check out the

Downloads are available on:


Configuration

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

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

Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.


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

This PR has been generated by Mend Renovate. View repository job log here.

@renovate renovate bot requested a review from a team as a code owner March 16, 2024 01:26
@renovate renovate bot requested review from Weakky and removed request for a team March 16, 2024 01:26
Copy link

codspeed-hq bot commented Mar 16, 2024

CodSpeed Performance Report

Merging #4775 will not alter performance

⚠️ No base runs were found

Falling back to comparing renovate/patch-driver-adapters-directory (03e9555) with main (473ed31)

Summary

✅ 11 untouched benchmarks

Copy link
Contributor

github-actions bot commented Mar 16, 2024

WASM Query Engine file Size

Engine This PR Base branch Diff
Postgres 2.079MiB 2.079MiB 0.000B
Postgres (gzip) 821.406KiB 821.407KiB -1.000B
Mysql 2.050MiB 2.050MiB 0.000B
Mysql (gzip) 808.543KiB 808.542KiB 1.000B
Sqlite 1.945MiB 1.945MiB 0.000B
Sqlite (gzip) 769.427KiB 769.427KiB 0.000B

Copy link
Contributor

github-actions bot commented Mar 16, 2024

✅ WASM query-engine performance won't change substantially (0.998x)

Full benchmark report
DATABASE_URL="postgresql://postgres:postgres@localhost:5432/bench?schema=imdb_bench&sslmode=disable" \
node --experimental-wasm-modules query-engine/driver-adapters/executor/dist/bench.mjs
"
"
"
"
"
"
"
"
"
"
"
"
"
"
"
"
"
"
"
"
"
"
"
"
"
"
"
"
"
"
"
"
"
"
"
"
cpu: AMD EPYC 7763 64-Core Processor
runtime: node v18.19.1 (x64-linux)

benchmark                   time (avg)             (min … max)       p75       p99      p999
-------------------------------------------------------------- -----------------------------
• movies.findMany() (all - ~50K)
-------------------------------------------------------------- -----------------------------
Web Assembly: Baseline     360 ms/iter       (359 ms … 362 ms)    362 ms    362 ms    362 ms
Web Assembly: Latest       446 ms/iter       (445 ms … 447 ms)    447 ms    447 ms    447 ms
Web Assembly: Current      448 ms/iter       (446 ms … 452 ms)    449 ms    452 ms    452 ms
Node API: Current          199 ms/iter       (195 ms … 203 ms)    201 ms    203 ms    203 ms

summary for movies.findMany() (all - ~50K)
  Web Assembly: Current
   2.25x slower than Node API: Current
   1.24x slower than Web Assembly: Baseline
   1x faster than Web Assembly: Latest

• movies.findMany({ take: 2000 })
-------------------------------------------------------------- -----------------------------
Web Assembly: Baseline  14'711 µs/iter (14'578 µs … 15'526 µs) 14'688 µs 15'526 µs 15'526 µs
Web Assembly: Latest    18'174 µs/iter (17'940 µs … 19'525 µs) 18'289 µs 19'525 µs 19'525 µs
Web Assembly: Current   18'077 µs/iter (17'915 µs … 18'263 µs) 18'122 µs 18'263 µs 18'263 µs
Node API: Current        7'956 µs/iter   (7'745 µs … 8'226 µs)  7'995 µs  8'226 µs  8'226 µs

summary for movies.findMany({ take: 2000 })
  Web Assembly: Current
   2.27x slower than Node API: Current
   1.23x slower than Web Assembly: Baseline
   1.01x faster than Web Assembly: Latest

• movies.findMany({ where: {...}, take: 2000 })
-------------------------------------------------------------- -----------------------------
Web Assembly: Baseline   2'295 µs/iter   (2'202 µs … 3'566 µs)  2'283 µs  3'329 µs  3'566 µs
Web Assembly: Latest     2'841 µs/iter   (2'732 µs … 4'981 µs)  2'821 µs  3'666 µs  4'981 µs
Web Assembly: Current    2'832 µs/iter   (2'733 µs … 4'637 µs)  2'817 µs  3'656 µs  4'637 µs
Node API: Current        1'391 µs/iter   (1'311 µs … 1'669 µs)  1'404 µs  1'638 µs  1'669 µs

summary for movies.findMany({ where: {...}, take: 2000 })
  Web Assembly: Current
   2.04x slower than Node API: Current
   1.23x slower than Web Assembly: Baseline
   1x faster than Web Assembly: Latest

• movies.findMany({ include: { cast: true } take: 2000 }) (m2m)
-------------------------------------------------------------- -----------------------------
Web Assembly: Baseline     569 ms/iter       (563 ms … 585 ms)    576 ms    585 ms    585 ms
Web Assembly: Latest       747 ms/iter       (741 ms … 767 ms)    750 ms    767 ms    767 ms
Web Assembly: Current      741 ms/iter       (736 ms … 749 ms)    748 ms    749 ms    749 ms
Node API: Current          456 ms/iter       (443 ms … 469 ms)    469 ms    469 ms    469 ms

summary for movies.findMany({ include: { cast: true } take: 2000 }) (m2m)
  Web Assembly: Current
   1.62x slower than Node API: Current
   1.3x slower than Web Assembly: Baseline
   1.01x faster than Web Assembly: Latest

• movies.findMany({ where: {...}, include: { cast: true } take: 2000 }) (m2m)
-------------------------------------------------------------- -----------------------------
Web Assembly: Baseline  78'711 µs/iter (78'478 µs … 79'171 µs) 78'940 µs 79'171 µs 79'171 µs
Web Assembly: Latest       105 ms/iter       (104 ms … 105 ms)    105 ms    105 ms    105 ms
Web Assembly: Current      105 ms/iter       (104 ms … 105 ms)    105 ms    105 ms    105 ms
Node API: Current       59'842 µs/iter (59'176 µs … 60'260 µs) 60'145 µs 60'260 µs 60'260 µs

summary for movies.findMany({ where: {...}, include: { cast: true } take: 2000 }) (m2m)
  Web Assembly: Current
   1.75x slower than Node API: Current
   1.33x slower than Web Assembly: Baseline
   1x faster than Web Assembly: Latest

• movies.findMany({ take: 2000, include: { cast: { include: { person: true } } } })
-------------------------------------------------------------- -----------------------------
Web Assembly: Baseline   1'003 ms/iter     (998 ms … 1'010 ms)  1'008 ms  1'010 ms  1'010 ms
Web Assembly: Latest     1'243 ms/iter   (1'235 ms … 1'266 ms)  1'248 ms  1'266 ms  1'266 ms
Web Assembly: Current    1'244 ms/iter   (1'233 ms … 1'293 ms)  1'241 ms  1'293 ms  1'293 ms
Node API: Current          859 ms/iter       (836 ms … 897 ms)    880 ms    897 ms    897 ms

summary for movies.findMany({ take: 2000, include: { cast: { include: { person: true } } } })
  Web Assembly: Current
   1.45x slower than Node API: Current
   1.24x slower than Web Assembly: Baseline
   1x faster than Web Assembly: Latest

• movie.findMany({ where: { ... }, take: 2000, include: { cast: { include: { person: true } } } })
-------------------------------------------------------------- -----------------------------
Web Assembly: Baseline     141 ms/iter       (140 ms … 142 ms)    142 ms    142 ms    142 ms
Web Assembly: Latest       173 ms/iter       (172 ms … 173 ms)    173 ms    173 ms    173 ms
Web Assembly: Current      173 ms/iter       (173 ms … 174 ms)    173 ms    174 ms    174 ms
Node API: Current          103 ms/iter       (101 ms … 104 ms)    104 ms    104 ms    104 ms

summary for movie.findMany({ where: { ... }, take: 2000, include: { cast: { include: { person: true } } } })
  Web Assembly: Current
   1.69x slower than Node API: Current
   1.23x slower than Web Assembly: Baseline
   1x faster than Web Assembly: Latest

• movie.findMany({ where: { reviews: { author: { ... } }, take: 100 }) (to-many -> to-one)
-------------------------------------------------------------- -----------------------------
Web Assembly: Baseline   1'037 µs/iter     (980 µs … 1'794 µs)  1'033 µs  1'513 µs  1'794 µs
Web Assembly: Latest     1'357 µs/iter   (1'291 µs … 1'954 µs)  1'353 µs  1'852 µs  1'954 µs
Web Assembly: Current    1'362 µs/iter   (1'300 µs … 2'192 µs)  1'365 µs  1'776 µs  2'192 µs
Node API: Current          794 µs/iter     (696 µs … 1'252 µs)    798 µs  1'154 µs  1'252 µs

summary for movie.findMany({ where: { reviews: { author: { ... } }, take: 100 }) (to-many -> to-one)
  Web Assembly: Current
   1.71x slower than Node API: Current
   1.31x slower than Web Assembly: Baseline
   1x faster than Web Assembly: Latest

• movie.findMany({ where: { cast: { person: { ... } }, take: 100 }) (m2m -> to-one)
-------------------------------------------------------------- -----------------------------
Web Assembly: Baseline   1'070 µs/iter   (1'020 µs … 1'894 µs)  1'062 µs  1'697 µs  1'894 µs
Web Assembly: Latest     1'347 µs/iter   (1'297 µs … 1'854 µs)  1'353 µs  1'676 µs  1'854 µs
Web Assembly: Current    1'360 µs/iter   (1'301 µs … 1'776 µs)  1'366 µs  1'713 µs  1'776 µs
Node API: Current          788 µs/iter       (749 µs … 994 µs)    801 µs    856 µs    994 µs

summary for movie.findMany({ where: { cast: { person: { ... } }, take: 100 }) (m2m -> to-one)
  Web Assembly: Current
   1.73x slower than Node API: Current
   1.27x slower than Web Assembly: Baseline
   1.01x slower than Web Assembly: Latest

After changes in 6f3bff5

@renovate renovate bot force-pushed the renovate/patch-driver-adapters-directory branch from a8d203c to c31aeba Compare March 23, 2024 01:14
@renovate renovate bot force-pushed the renovate/patch-driver-adapters-directory branch from c31aeba to 6f3bff5 Compare March 30, 2024 02:05
@renovate renovate bot force-pushed the renovate/patch-driver-adapters-directory branch from 6f3bff5 to 03e9555 Compare April 3, 2024 06:34
@Jolg42 Jolg42 merged commit fa0e267 into main Apr 3, 2024
173 of 183 checks passed
@Jolg42 Jolg42 deleted the renovate/patch-driver-adapters-directory branch April 3, 2024 07:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant