[dependabot]

Bumps the cloudflare group with 2 updates: @cloudflare/workers-types and wrangler.

Updates @cloudflare/workers-types from 5.20261023.1 to 5.20261030.1

Commits

• See full diff in compare view

Updates wrangler from 4.152.0 to 4.156.0

Release notes

Sourced from wrangler's releases.

wrangler@4.156.0

Minor Changes

• #16532 25802bc Thanks @​simonha9! - Allow the experimental wrangler d1 insights command to run across every D1 database in the account

  The database name is now optional. With no name, the command returns the top queries across every D1 database in the account, and each result gains a databaseId field.

Patch Changes

• #16369 ec0bea4 Thanks @​MattieTK! - Stop autoconfig in non-interactive runs when a project root holds both static files and a Pages functions directory

  When a project without a detected framework has a functions directory, autoconfig asks whether it is a Cloudflare Pages project. Non-interactive runs (CI and coding agents) assume it is not and continue as a static site. When the static files are in the project root, that deploys the root as static assets, and the Pages Functions (the project's API routes) are not deployed.

  In that case autoconfig now stops with an error explaining that Pages Functions cannot be migrated automatically yet. For Pages Functions it suggests moving the static files into a subdirectory and deploying with wrangler pages deploy, or migrating the Functions to a Worker; for a functions directory that is not Pages Functions, it suggests moving the static files into a subdirectory or adding a configuration file. Projects whose static files are already in a subdirectory, projects detected as Pages or with a detected framework, and interactive runs where the user answers the prompt are unaffected.

• #16367 b4653b4 Thanks @​MattieTK! - Write a protective .assetsignore when autoconfig uses the project root as the static assets directory

  Autoconfig is meant to write an .assetsignore when the project root itself is the assets directory, so that local files are not uploaded as public assets. The check compared the detected output directory, which is relative ("."), with the absolute project path, so it never matched and no .assetsignore was written. A static project with an index.html at its root (for example after wrangler setup or a zero-config wrangler deploy) then uploaded files such as .env, .dev.vars, .git and node_modules as public assets.

  The check now resolves the assets directory that the generated configuration uses and compares it with the project root, so frameworks that set their own build output directory (such as Nuxt or SvelteKit) do not get an unused root .assetsignore. The generated .assetsignore also covers what a Cloudflare Pages upload skips, alongside the existing .wrangler, .dev.vars* and .env* entries: /_worker.js, /_routes.json and /functions at the root (so nested paths such as blog/functions/index.html are still uploaded), node_modules, .git and .DS_Store at any depth, and .npmrc. If an existing .assetsignore only lists a narrower pattern such as .env, .env* is added so that files like .env.production are skipped too. When the project root of an assets-only project contains a Pages functions directory or _worker.js, autoconfig now warns that it will not be deployed, since it is excluded from the assets and not run as server code.

• #16532 25802bc Thanks @​simonha9! - Fail the experimental wrangler d1 insights command with an actionable error when the GraphQL Analytics API rejects the request

  Previously the command printed an empty []. Rate limit errors now say how long to wait before retrying, and authorization errors name the "Account Analytics: Read" permission the API token needs.

• #16013 8b64bec Thanks @​swalker326! - Fix Durable Object self-references in tests and container validation

  Durable Object bindings that explicitly name the Worker itself now resolve to the test runner in @cloudflare/vitest-plugin, for both cloudflare.config.ts and Wrangler configuration files. Named Wrangler environments use their effective Worker name, keeping bindings to the base Worker external. Container validation also accepts these self-references, using the effective deployment name to distinguish local and external bindings.

  Explicit binding targets remain intact during configuration conversion, so deploying with --name or a CI name override preserves the intended Durable Object target.

• Updated dependencies [15fbaed, d8899ac]:

  • miniflare@5.20261023.3-beta

wrangler@4.155.0

Minor Changes

• #16536 a95d647 Thanks @​WalshyDev! - Support remote Analytics Engine bindings in local development

  Setting remote: true on an Analytics Engine dataset now sends writeDataPoint() calls from wrangler dev and the Vite plugin to the real dataset. Without it, writes are still dropped locally.

  {
    "analytics_engine_datasets": [
      {
        "binding": "EVENTS",
        "dataset": "my-dataset",
        "remote": true
      }
    ]

... (truncated)

Commits

• See full diff 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 show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore <dependency name> 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 <dependency name> 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 <dependency name> 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 <dependency name> will remove all of the ignore conditions of the specified dependency
• @dependabot unignore <dependency name> <ignore condition> will remove the ignore condition of the specified dependency and ignore conditions