Skip to content

fix(deps): update all non-major dependencies - #1427

Open
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/all-minor-patch
Open

fix(deps): update all non-major dependencies#1427
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/all-minor-patch

Conversation

@renovate

@renovate renovate Bot commented Aug 17, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

ℹ️ Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package Change Age Confidence
@cloudflare/vite-plugin (source) ^1.51.1 → ^1.53.0 age confidence
@swc/core (source) ^1.15.47 → ^1.16.0 age confidence
@swc/plugin-emotion (source) ^14.15.0 → ^14.19.0 age confidence
@swc/plugin-styled-components (source) ^12.15.0 → ^12.19.0 age confidence
es-module-lexer ^2.3.1 → ^2.3.2 age confidence
eslint-plugin-regexp ^3.1.1 → ^3.2.0 age confidence
globals ^17.9.0 → ^17.11.0 age confidence
oxfmt (source) ^0.62.0 → ^0.64.0 age confidence
rolldown (source) ^1.2.3 → ^1.2.4 age confidence
styled-components (source) ^6.5.1 → ^6.5.3 age confidence
typescript-eslint (source) ^8.66.0 → ^8.67.0 age confidence
vitest (source) ^4.1.10 → ^4.1.11 age confidence
wrangler (source) ^4.120.0 → ^4.124.0 age confidence

Release Notes

cloudflare/workers-sdk (@​cloudflare/vite-plugin)

v1.53.0

Compare Source

Minor Changes

  • #​15026 6529f0c Thanks @​petebacondarwin! - Allow containers to be attached to a Durable Object from its exports entry

    A container can now be linked to its Durable Object from the export side, using a new container field that names an entry in the containers array. As a result containers[].class_name is now optional — a container that is referenced this way only needs a name:

    {
  "name": "my-worker",
  "main": "worker.js",
  "compatibility_date": "2026-07-01",
  "containers": [
    { "name": "my-container", "image": "./Dockerfile", "max_instances": 1 }
  ],
  "exports": {
    "MyContainerDO": {
      "type": "durable-object",
      "storage": "sqlite",
      "container": "my-container"
    }
  }
}

    The existing containers[].class_name direction keeps working and either direction may be used, but the two must agree: a container that names its Durable Object cannot also be claimed by a different one.

    container is only valid on live durable-object exports (created and expecting-transfer) and requires storage: "sqlite". Wrangler now also reports an error when:

    • a container reference names a container that does not exist
    • two Durable Object exports claim the same container
    • a container and a Durable Object export disagree about which one they are linked to
    • a container ends up linked to no Durable Object at all
    • two containers share a name
    • a container's class_name names a Durable Object whose storage is legacy-kv
    • two containers are attached to the same Durable Object

    That last case was previously accepted but could never work: workerd attaches a single container per Durable Object namespace, and in local development every container for a class builds into the same image tag, so one silently overwrote the other. If you have two containers on one class_name, give each its own Durable Object class.

Patch Changes

  • #​15238 3a4fc6b Thanks @​jamesopstad! - Honor access.dev when running Workers with @cloudflare/vite-plugin, so ctx.access.getIdentity() returns the configured identity.

  • #​15028 d4f441f Thanks @​harshmathurx! - Handle Worker-side request body cancellation without surfacing stream controller errors in local dev.

  • #​15185 1f79ace Thanks @​jamesopstad! - Use a fixed default compatibility date rather than the current date

    When no compatibility date was set, Wrangler, C3 and the Vitest pool all defaulted to the current date. workerd only accepts a compatibility date up to 7 days beyond its own release, so whenever a workerd release was delayed the default could get ahead of the runtime that had been installed, and local development would fail to start.

    The default is now fixed at the release date of the workerd version that ships with each release, which leaves a week of headroom and updates as workerd is upgraded. @cloudflare/vite-plugin previously inlined the date at which it was built. It now shares the same default.

  • #​15239 f431166 Thanks @​jamesopstad! - Prevent date-enabled Node.js compatibility from adding conflicting globals to generated runtime types

    Runtime type generation now treats Node.js compatibility enabled by a compatibility date the same way as an explicit nodejs_compat flag. Node.js globals continue to come from @types/node instead of being generated as any declarations that override those types.

  • #​15196 8fb2b87 Thanks @​skepticfx! - Use the FedRAMP High managed container registry when Wrangler targets the FedRAMP High compliance region

    Container builds, pushes, deployments, image commands, and local development now select the corresponding production or staging FedRAMP registry and API from either compliance_region or CLOUDFLARE_COMPLIANCE_REGION.

  • Updated dependencies [bc5726b, 1277a72, ba54f0d, 6529f0c, b7422b0, 186339c, 4f922dc, 4d74b8d, 2e0c962, 1f79ace, 49f73de, 7cee278, 8777180, 265256a, 1f79ace, f431166, 8fb2b87, 75cf407]:

v1.52.1

Compare Source

Patch Changes

v1.52.0

Compare Source

Minor Changes

  • #​15123 d0c976c Thanks @​dependabot! - Detect Node.js compatibility from the compatibility date, now that nodejs_compat is enabled by default

    As of compatibility date 2026-08-04, workerd enables the nodejs_compat and nodejs_compat_v2 compatibility flags by default. Previously these tools only treated Node.js compatibility as enabled when one of those flags was listed explicitly, so a Worker on a compatibility date of 2026-08-04 or later without the flag would get Node.js APIs from the runtime but no Node.js polyfills from the bundler, and process.env could be substituted with an empty object at build time. They now resolve these flags the same way workerd does, and honour no_nodejs_compat to opt out.

    To keep Node.js compatibility switched off on a newer compatibility date, specify both no_nodejs_compat and no_nodejs_compat_v2, since each flag has its own default.

    @cloudflare/vitest-pool-workers needs nodejs_compat_v2 for its own test runner, so it continues to override a project that opts out of it. On a compatibility date that enables the flag anyway, it now drops the opt-out rather than adding the flag back, which workerd would reject — previously this stopped such a project from running any tests at all.

    wrangler types also no longer attributes its @types/node suggestion to "the nodejs_compat flag", which it can now make for Workers that do not set the flag at all.

Patch Changes

  • #​15148 0b82b15 Thanks @​jamesopstad! - Ignore a nodejs_compat compatibility flag that the compatibility date already enables

    workerd rejects a compatibility flag that its compatibility date enables by default, so a Worker configured with both a compatibility date of 2026-08-04 or later and nodejs_compat failed to start locally with "The compatibility flag nodejs_compat became the default as of 2026-08-04 so does not need to be specified anymore".

    The redundant nodejs_compat and nodejs_compat_v2 flags are now dropped when starting the runtime, which has no effect on the resulting Worker because the compatibility date enables both anyway. no_nodejs_compat and no_nodejs_compat_v2 still switch Node.js compatibility off, and a flag specified alongside its own opt-out is left alone so that workerd still reports those as contradictory.

  • Updated dependencies [d0c976c, d0c976c, 0b82b15, d0c976c, d0c976c, 90dd5e5, 3b02915]:

v1.51.3

Compare Source

Patch Changes

v1.51.2

Compare Source

Patch Changes
swc-project/swc (@​swc/core)

v1.16.0

Compare Source

Bug Fixes
Miscellaneous Tasks
Refactor
swc-project/plugins (@​swc/plugin-emotion)

v14.19.0

Minor Changes
  • 8d2db7f: build: Update swc_core to v76.0.0
swc-project/plugins (@​swc/plugin-styled-components)

v12.19.0

Minor Changes
  • 8d2db7f: build: Update swc_core to v76.0.0
guybedford/es-module-lexer (es-module-lexer)

v2.3.2

Compare Source

What's Changed

New Contributors

Full Changelog: guybedford/es-module-lexer@2.3.1...2.3.2

ota-meshi/eslint-plugin-regexp (eslint-plugin-regexp)

v3.2.0

Compare Source

Minor Changes
  • fix(deps): update dependency jsdoc-type-pratt-parser to v9 (#​1014)
sindresorhus/globals (globals)

v17.11.0

Compare Source

v17.10.0

Compare Source

oxc-project/oxc (oxfmt)

v0.64.0

Compare Source

🚀 Features
📚 Documentation

v0.63.0

Compare Source

rolldown/rolldown (rolldown)

v1.2.4

Compare Source

🚀 Features
🐛 Bug Fixes
📚 Documentation
🧪 Testing
  • browser: smoke test the packed @rolldown/browser in a real browser page (#​10634) by @​hyfdev
  • node-wasi: run the full node test suite against the WASI binding (#​10616) by @​hyfdev
  • webcontainer: smoke test the packed WASI artifacts inside a WebContainer (#​10626) by @​hyfdev
⚙️ Miscellaneous Tasks
styled-components/styled-components (styled-components)

v6.5.3

Compare Source

Patch Changes
  • 3470387: Fix TypeScript errors in projects that augment React HTML props with a data-* template-literal index signature.

v6.5.2

Compare Source

Patch Changes

  • 00b9ee2: .attrs() is cheaper to type-check.

    Two costs on the .attrs path are gone. Object-form .attrs() left the rendered target unchanged but still re-resolved that target's whole prop bag on every call, making .attrs on an HTML or SVG tag far costlier than on a wrapped component; it now reuses the props already resolved for the tag. Separately, making attrs-provided keys optional ran an avoidably expensive pass over the target's full prop set on every attrs component. Together these cut consumer type-check work measurably across every .attrs form, with no change to the resulting component's accepted props. Redirecting the target with .attrs({ as }), including the function form, is unaffected.

  • 00b9ee2: Explicitly annotated styled components type-check faster.

    Assigning a styled component to an explicit type, as isolatedDeclarations and any package that emits .d.ts files must (const Button: IStyledComponentBase<'web', ...> = styled.button``), used to be several times more expensive to check than an inferred one, because the annotation's styleand the component's widenedstyle` were two different csstype representations that the checker compared property by property.

    The inline style widening now builds on React's own CSSProperties, the same type a hand-written annotation carries, so that comparison short-circuits. On a 40-component fixture this cut the types created for the annotated pattern by about 21%, with no change to what style accepts: CSS custom properties, a component's own narrow style, and style={undefined} all behave exactly as before.

  • 00b9ee2: styled() wrapping a generic polymorphic component keeps its declared props narrow.

    Wrapping a component whose props are generic over an element type, such as the common <C extends React.ElementType>(props: PolymorphicProps<C, OwnProps>) pattern, used to let the styled result accept prop values the component itself rejects: styled(Button) would take variant="anything" even though <Button variant="anything"> is a type error. The wrapper now narrows those props exactly as the direct component does, so a bad value is caught in both places. Valid props, children, and plain (non-generic) targets are unaffected.

typescript-eslint/typescript-eslint (typescript-eslint)

v8.67.0

Compare Source

🚀 Features
  • typescript-eslint: export basic globs for using tseslint (#​12105)
❤️ Thank You

See GitHub Releases for more information.

You can read about our versioning strategy and releases on our website.

vitest-dev/vitest (vitest)

v4.1.11

Compare Source

   🐞 Bug Fixes
    View changes on GitHub
cloudflare/workers-sdk (wrangler)

v4.124.0

Compare Source

Minor Changes

  • #​15026 6529f0c Thanks @​petebacondarwin! - Allow containers to be attached to a Durable Object from its exports entry

    A container can now be linked to its Durable Object from the export side, using a new container field that names an entry in the containers array. As a result containers[].class_name is now optional — a container that is referenced this way only needs a name:

    {
  "name": "my-worker",
  "main": "worker.js",
  "compatibility_date": "2026-07-01",
  "containers": [
    { "name": "my-container", "image": "./Dockerfile", "max_instances": 1 }
  ],
  "exports": {
    "MyContainerDO": {
      "type": "durable-object",
      "storage": "sqlite",
      "container": "my-container"
    }
  }
}

    The existing containers[].class_name direction keeps working and either direction may be used, but the two must agree: a container that names its Durable Object cannot also be claimed by a different one.

    container is only valid on live durable-object exports (created and expecting-transfer) and requires storage: "sqlite". Wrangler now also reports an error when:

    • a container reference names a container that does not exist
    • two Durable Object exports claim the same container
    • a container and a Durable Object export disagree about which one they are linked to
    • a container ends up linked to no Durable Object at all
    • two containers share a name
    • a container's class_name names a Durable Object whose storage is legacy-kv
    • two containers are attached to the same Durable Object

    That last case was previously accepted but could never work: workerd attaches a single container per Durable Object namespace, and in local development every container for a class builds into the same image tag, so one silently overwrote the other. If you have two containers on one class_name, give each its own Durable Object class.

Patch Changes

  • #​15211 bc5726b Thanks @​nithin42! - Honor access.dev when running Workers with @cloudflare/vitest-pool-workers, so ctx.access.getIdentity() returns the configured identity just as it does with wrangler dev.

  • #​14999 ba54f0d Thanks @​mittalpk! - Fix .env loading on Windows leaking stale, differently-cased duplicate keys

    On Windows, wrangler loads .env values through a case-insensitive Proxy wrapper so lookups like env.PATH and env.Path resolve to the same value, and this object is assigned directly to process.env. When a key was set again under a different casing (e.g. a value in .env.local overriding one from .env with different casing), the previous casing was never removed from the underlying object. env.PATH/env.Path still returned the correct, latest value, but anything that enumerates process.env — Object.keys, for...in, JSON.stringify, object spread, or a spawned subprocess inheriting the environment — would see both the stale and current key.

    Duplicate entries no longer appear, so environment variables passed to subprocesses and any code that lists the environment now see only the latest value for each variable.

  • #​15044 b7422b0 Thanks @​stareezy-1! - Normalize structural CRLF line endings before sending D1 commands to the remote query API

    wrangler d1 migrations apply --remote and wrangler d1 execute --remote --command failed with incomplete input: SQLITE_ERROR when the SQL contained CRLF line endings inside a compound statement such as a CREATE TRIGGER ... BEGIN ... END; body. Structural line endings are now normalized to LF before the command is sent to the D1 query API, while CRLF inside quoted values and identifiers remains unchanged.

  • #​15046 186339c Thanks @​erwinzhang7! - Fixes D1 SQL statements not handling lowercase ends correctly

    wrangler d1 execute and wrangler d1 migrations apply split a SQL file into statements before running them. A BEGIN or CASE block closed with a lowercase end was not recognised as closed, so every statement after it was folded into that block instead of being run on its own. SQLite accepts either case, so a file like this applied only the trigger and silently skipped the table:

    CREATE TRIGGER IF NOT EXISTS update_trigger AFTER UPDATE ON items
begin
	DELETE FROM updates WHERE item_id=old.id;
end;
CREATE TABLE after_the_trigger (id TEXT PRIMARY KEY);

    Files written with an uppercase END were unaffected. Both cases now behave the same.

  • #​15231 4f922dc Thanks @​dependabot! - Update dependencies of "miniflare", "wrangler"

    The following dependency versions have been updated:

    Dependency From To
    @​cloudflare/workers-types ^5.20260811.1 ^5.20260814.1
    workerd 1.20260811.1 1.20260814.1

  • #​15248 4d74b8d Thanks @​dependabot! - Update dependencies of "miniflare", "wrangler"

    The following dependency versions have been updated:

    Dependency From To
    @​cloudflare/workers-types ^5.20260814.1 ^5.20260815.1
    workerd 1.20260814.1 1.20260815.1

  • #​15185 1f79ace Thanks @​jamesopstad! - Resolve --latest to the newest compatibility date supported by the installed runtime

    wrangler deploy --latest and wrangler versions upload --latest resolved the compatibility date to the current date, and wrangler pages download config did the same for projects configured to always use the latest compatibility date. Both write that date into a configuration file for subsequent commands to use, so a date that the installed workerd did not yet support left the project unable to run wrangler dev.

    These now resolve to the latest compatibility date supported by this version of Wrangler, which is the release date of the workerd it ships with.

  • #​15151 49f73de Thanks @​maximilliangrand! - Fix spurious Trailing comma jsonc(519) warnings for wrangler.jsonc in VS Code 1.131+

    Trailing commas in wrangler.jsonc files that reference Wrangler's JSON schema are no longer reported as errors by recent versions of VS Code. Wrangler always accepted these files; only the editor warning was wrong.

  • #​14983 7cee278 Thanks @​kdelay! - Respect CLOUDFLARE_ACCOUNT_ID in wrangler pages project list, create and delete

    These three commands could target a previously used account even when CLOUDFLARE_ACCOUNT_ID was set, failing with Authentication error [code: 10000] in setups with more than one account. They now use the account named by CLOUDFLARE_ACCOUNT_ID, matching the rest of wrangler pages. When the variable is unset, the previously used account is still selected, as before.

  • #​15153 265256a Thanks @​podonnell-dev! - Fix wrangler preview base-config commands showing an inherited script positional

  • #​15185 1f79ace Thanks @​jamesopstad! - Use a fixed default compatibility date rather than the current date

    When no compatibility date was set, Wrangler, C3 and the Vitest pool all defaulted to the current date. workerd only accepts a compatibility date up to 7 days beyond its own release, so whenever a workerd release was delayed the default could get ahead of the runtime that had been installed, and local development would fail to start.

    The default is now fixed at the release date of the workerd version that ships with each release, which leaves a week of headroom and updates as workerd is upgraded. @cloudflare/vite-plugin previously inlined the date at which it was built. It now shares the same default.

  • #​15239 f431166 Thanks @​jamesopstad! - Prevent date-enabled Node.js compatibility from adding conflicting globals to generated runtime types

    Runtime type generation now treats Node.js compatibility enabled by a compatibility date the same way as an explicit nodejs_compat flag. Node.js globals continue to come from @types/node instead of being generated as any declarations that override those types.

  • #​15196 8fb2b87 Thanks @​skepticfx! - Use the FedRAMP High managed container registry when Wrangler targets the FedRAMP High compliance region

    Container builds, pushes, deployments, image commands, and local development now select the corresponding production or staging FedRAMP registry and API from either compliance_region or CLOUDFLARE_COMPLIANCE_REGION.

  • #​15082 75cf407 Thanks @​penalosa! - Enable the new configuration format in the cf-wrangler dev delegate

    Projects started through cf dev now load cloudflare.config.ts and optional wrangler.config.ts, matching the configuration used by the delegate's build path.

  • Updated dependencies [1277a72, 4f922dc, 4d74b8d, 2e0c962, 8777180]:

v4.123.0

Compare Source

Minor Changes

  • #​15113 b8fd112 Thanks @​BSFishy! - Add local dev simulation for Cloudflare Access ctx.access.getIdentity()

    You can now configure a mock Cloudflare Access identity in wrangler.json so that ctx.access.getIdentity() returns it during local development.

    // wrangler.json
{
  "access": {
    "dev": {
      "aud": "my-app-aud-tag",
      "identity": {
        "email": "user@example.com",
        "name": "Test User"
      }
    }
  }
}

  • #​15152 f0f2054 Thanks @​GregBrimble! - [private beta]: Updates the --ignore-defaults flag to --ignore-base-config on wrangler preview commands.

    --ignore-base-config now only takes effect on Preview creation, rather than on each deployment, since Preview base configuration is now copy-on-create rather than inherit-on-deploy.

  • #​14872 339509d Thanks @​dario-piotrowicz! - Add automatic update prompts for out-of-date Cloudflare agent skills

    When Cloudflare skills were previously installed by Wrangler and the upstream cloudflare/skills repository has newer content, Wrangler now offers to update them after eligible commands complete.

    To re

✂ Note

PR body was truncated to here.

Configuration

📅 Schedule: (UTC)

  • Branch creation
    • Between 12:00 AM and 03:59 AM, only on Monday (* 0-3 * * 1)
  • 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 was generated by Mend Renovate. View the repository job log.

@renovate
renovate Bot force-pushed the renovate/all-minor-patch branch from 1890300 to 6c57080 Compare August 18, 2026 14:11
@renovate
renovate Bot force-pushed the renovate/all-minor-patch branch from 6c57080 to 65cec44 Compare August 18, 2026 21:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

dependencies

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

0 participants