fix(deps): update all non-major dependencies (master)

[renovate]

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
@apollo/gateway	^0.51.0 -> ^0.52.0
@apollo/subgraph	^0.4.0 -> ^0.5.0
@aws-cdk/assert	2.37.0 -> 2.37.1
@graphql-tools/schema	9.0.0 -> 9.0.1
@graphql-tools/url-loader	7.13.4 -> 7.13.5
@guild-docs/algolia	0.2.0 -> 0.2.2
@types/aws-lambda	8.10.101 -> 8.10.102
aws-cdk	2.37.0 -> 2.37.1
aws-cdk-lib	2.37.0 -> 2.37.1
esbuild	^0.14.21 -> ^0.15.0
graphql-scalars	1.17.0 -> 1.18.0
wrangler	2.0.24 -> 2.0.25

---

Release Notes

apollographql/federation (@​apollo/gateway)

v0.52.0

Compare Source

apollographql/federation (@​apollo/subgraph)

v0.5.0

Compare Source

aws/aws-cdk

v2.37.1

Compare Source

Bug Fixes

• eks: revert "fix(eks): cannot disable cluster logging once it has been enabled" (#​21545) (5515ce4)

---

Alpha modules (2.37.1-alpha.0)

ardatan/graphql-tools (@​graphql-tools/schema)

v9.0.1

Compare Source

Patch Changes

• #​4643 2609d71f Thanks @​ardatan! - Revert the breaking change introduced in @graphql-tools/merge

• Updated dependencies [2609d71f]:

  • @​graphql-tools/utils@​8.10.0
  • @​graphql-tools/merge@​8.3.3

ardatan/graphql-tools (@​graphql-tools/url-loader)

v7.13.5

Compare Source

Patch Changes

• Updated dependencies [2609d71f]:
  • @​graphql-tools/utils@​8.10.0
  • @​graphql-tools/delegate@​9.0.1
  • @​graphql-tools/wrap@​9.0.1

the-guild-org/the-guild-docs

v0.2.2

Compare Source

v0.2.1

Compare Source

evanw/esbuild

v0.15.0

Compare Source

This release contains backwards-incompatible changes. Since esbuild is before version 1.0.0, these changes have been released as a new minor version to reflect this (as recommended by npm). You should either be pinning the exact version of esbuild in your package.json file or be using a version range syntax that only accepts patch upgrades such as ~0.14.0. See the documentation about semver for more information.

• Implement the Yarn Plug'n'Play module resolution algorithm (#​154, #​237, #​1263, #​2451)

  Node comes with a package manager called npm, which installs packages into a node_modules folder. Node and esbuild both come with built-in rules for resolving import paths to packages within node_modules, so packages installed via npm work automatically without any configuration. However, many people use an alternative package manager called Yarn. While Yarn can install packages using node_modules, it also offers a different package installation strategy called Plug'n'Play, which is often shortened to "PnP" (not to be confused with pnpm, which is an entirely different unrelated package manager).

  Plug'n'Play installs packages as .zip files on your file system. The packages are never actually unzipped. Since Node doesn't know anything about Yarn's package installation strategy, this means you can no longer run your code with Node as it won't be able to find your packages. Instead, you need to run your code with Yarn, which applies patches to Node's file system APIs before running your code. These patches attempt to make zip files seem like normal directories. When running under Yarn, using Node's file system API to read ./some.zip/lib/file.js actually automatically extracts lib/file.js from ./some.zip at run-time as if it was a normal file. Other file system APIs behave similarly. However, these patches don't work with esbuild because esbuild is not written in JavaScript; it's a native binary executable that interacts with the file system directly through the operating system.

  Previously the workaround for using esbuild with Plug'n'Play was to use the @yarnpkg/esbuild-plugin-pnp plugin with esbuild's JavaScript API. However, this wasn't great because the plugin needed to potentially intercept every single import path and file load to check whether it was a Plug'n'Play package, which has an unusually high performance cost. It also meant that certain subtleties of path resolution rules within a .zip file could differ slightly from the way esbuild normally works since path resolution inside .zip files was implemented by Yarn, not by esbuild (which is due to a limitation of esbuild's plugin API).

  With this release, esbuild now contains an independent implementation of Yarn's Plug'n'Play algorithm (which is used when esbuild finds a .pnp.js, .pnp.cjs, or .pnp.data.json file in the directory tree). Creating additional implementations of this algorithm recently became possible because Yarn's package manifest format was recently documented: https://yarnpkg.com/advanced/pnp-spec/. This should mean that you can now use esbuild to bundle Plug'n'Play projects without any additional configuration (so you shouldn't need @yarnpkg/esbuild-plugin-pnp anymore). Bundling these projects should now happen much faster as Yarn no longer even needs to be run at all. Bundling the Yarn codebase itself with esbuild before and after this change seems to demonstrate over a 10x speedup (3.4s to 0.24s). And path resolution rules within Yarn packages should now be consistent with how esbuild handles regular Node packages. For example, fields such as module and browser in package.json files within .zip files should now be respected.

  Keep in mind that this is brand new code and there may be some initial issues to work through before esbuild's implementation is solid. Yarn's Plug'n'Play specification is also brand new and may need some follow-up edits to guide new implementations to match Yarn's exact behavior. If you try this out, make sure to test it before committing to using it, and let me know if anything isn't working as expected. Should you need to debug esbuild's path resolution, you may find --log-level=verbose helpful.

Urigo/graphql-scalars

v1.18.0

Compare Source

Minor Changes

• 4db9d82 Thanks
  @​saihaj! - CUID Scalar

  A field whose value conforms to the standard cuid format as specified in
  This Repo.

cloudflare/wrangler2

v2.0.25

Compare Source

Patch Changes

• #​1615 9163da17 Thanks @​huw! - fix: Resolve source maps correctly in local dev mode

  Resolves #​1614

• #​1617 32c9a4ae Thanks @​jahands! - fix: Ignore _routes.generated.json when uploading Pages assets

• #​1609 fa8cb73f Thanks @​jahands! - patch: Consolidate redundant routes when generating _routes.generated.json

  Example: ["/foo/:name", "/foo/bar"] => ["/foo/*"]

• #​1595 d4fbd0be Thanks @​caass! - Add support for Alarm Events in wrangler tail

  wrangler tail --format pretty now supports receiving events from Durable Object Alarms, and will display the time the alarm was triggered.

  Additionally, any future unknown events will simply print "Unknown Event" instead of crashing the wrangler process.

  Closes #​1519

• #​1642 a3e654f8 Thanks @​jrf0110! - feat: Add output-routes-path to functions build

  This controls the output path of the _routes.json file. Also moves _routes.json generation to tmp directory during functions build + publish

• #​1606 24327289 Thanks @​Skye-31! - chore: make prettier also fix changesets, as it causes checks to fail if they're not formatted

• #​1611 3df0fe04 Thanks @​GregBrimble! - feat: Durable Object multi-worker bindings in local dev.

  Building on the recent work for multi-worker Service bindings in local dev, this now adds support for direct Durable Object namespace bindings.

  A parent (calling) Worker will look for child Workers (where the Durable Object has been defined) by matching the script_name configuration option with the child's Service name. For example, if you have a Worker A which defines a Durable Object, MyDurableObject, and Worker B which references A's Durable Object:

  name = "A"
  
  [durable_objects]
  bindings = [
  	{ name = "MY_DO", class_name = "MyDurableObject" }
  ]

  name = "B"
  
  [durable_objects]
  bindings = [
  	{ name = "REFERENCED_DO", class_name = "MyDurableObject", script_name = "A" }
  ]

  MY_DO will work as normal in Worker A. REFERENCED_DO in Worker B will point at A's Durable Object.

  Note: this only works in local mode (wrangler dev --local) at present.

• #​1621 2aa3fe88 Thanks @​Skye-31! - fix(#​1487) [pages]: Command failed: git rev-parse --abrev-ref HEAD

• #​1631 f1c97c8b Thanks @​Skye-31! - chore: add fixtures to prettier

• #​1602 ebd1d631 Thanks @​huw! - fix: Pass usageModel to Miniflare in local dev

  This allows Miniflare to dynamically update the external subrequest limit for Unbound workers.

• #​1629 06915ff7 Thanks @​Skye-31! - fix: disallow imports in _worker.js (#​1214)

• #​1518 85ab8a93 Thanks @​jahands! - feature: Reduce Pages Functions executions for Asset-only requests in _routes.json

  Manually create a _routes.json file in your build output directory to specify routes. This is a set of inclusion/exclusion rules to indicate when to run a Pages project's Functions. Note: This is an experemental feature and is subject to change.

• #​1634 f6ea7e7b Thanks @​Skye-31! - feat: [pages] add loaders for .html & .txt

• #​1589 6aa96e49 Thanks @​Skye-31! - fix routing for URI encoded static requests

• #​1643 4b04a377 Thanks @​GregBrimble! - feat: Add --inspector-port argument to wrangler pages dev

• #​1641 5f5466ab Thanks @​GregBrimble! - feat: Add support for using external Durable Objects from wrangler pages dev.

  An external Durable Object can be referenced using npx wrangler pages dev ./public --do MyDO=MyDurableObject@api where the Durable Object is made available on env.MyDO, and is described in a Workers service (name = "api") with the class name MyDurableObject.

  You must have the api Workers service running in as another wrangler dev process elsewhere already in order to reference that object.

• #​1605 9e632cdd Thanks @​kimyvgy! - refactor: add --ip argument for wrangler pages dev & defaults IP to 0.0.0.0

  Add new argument --ip for the command wrangler pages dev, defaults to 0.0.0.0. The command wrangler dev is also defaulting to 0.0.0.0 instead of localhost.

• #​1604 9732fafa Thanks @​WalshyDev! - Added R2 support for wrangler pages dev. You can add an R2 binding with --r2 <BINDING>.

• #​1608 9f02758f Thanks @​jrf0110! - feat: Generate _routes.generated.json for Functions routing

  When using Pages Functions, a _routes.generated.json file is created to inform Pages how to route requests to a project's Functions Worker.

• #​1603 7ae059b3 Thanks @​JacobMGEvans! - feat: R2 Object Deletequote
  Improving the R2 objects management, added the functionality to delete objects in a bucket.

  resolves #​1584

---

Configuration

📅 Schedule: Branch creation - "after 10pm,before 6:00am" in timezone Europe/Warsaw, Automerge - At any time (no schedule defined).

🚦 Automerge: Enabled.

♻ 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, click this checkbox.

---

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

[changeset-bot]

⚠️ No Changeset found

Latest commit: 0e0575b

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[github-actions]

✅ Benchmark Results

     ✓ no_errors
     ✓ expected_result

     checks.........................: 100.00% ✓ 218232      ✗ 0     
     data_received..................: 29 MB   967 kB/s
     data_sent......................: 13 MB   418 kB/s
     http_req_blocked...............: avg=1.19µs   min=800ns   med=1µs     max=2.78ms  p(90)=1.4µs   p(95)=1.7µs   
     http_req_connecting............: avg=19ns     min=0s      med=0s      max=2.08ms  p(90)=0s      p(95)=0s      
   ✓ http_req_duration..............: avg=205.56µs min=134.9µs med=183.5µs max=17.2ms  p(90)=231.2µs p(95)=258.12µs
       { expected_response:true }...: avg=205.56µs min=134.9µs med=183.5µs max=17.2ms  p(90)=231.2µs p(95)=258.12µs
     http_req_failed................: 0.00%   ✓ 0           ✗ 109116
     http_req_receiving.............: avg=18.07µs  min=10.4µs  med=16.6µs  max=4.39ms  p(90)=21.4µs  p(95)=25.3µs  
     http_req_sending...............: avg=6µs      min=4µs     med=4.7µs   max=7.02ms  p(90)=7.4µs   p(95)=10.4µs  
     http_req_tls_handshaking.......: avg=0s       min=0s      med=0s      max=0s      p(90)=0s      p(95)=0s      
     http_req_waiting...............: avg=181.48µs min=114.6µs med=161.7µs max=17.1ms  p(90)=203µs   p(95)=226.5µs 
     http_reqs......................: 109116  3637.014433/s
     iteration_duration.............: avg=269.92µs min=195µs   med=244.8µs max=19.63ms p(90)=304.4µs p(95)=339.02µs
     iterations.....................: 109116  3637.014433/s
     vus............................: 1       min=1         max=1   
     vus_max........................: 1       min=1         max=1