chore: import upstream snapshot with attribution
Deploy (to testing) and Test Playground Preview Worker / Deploy Playground Preview Worker (testing) (push) Has been skipped
Deploy Workers Shared Staging / Deploy Workers Shared Staging (push) Failing after 0s
Prerelease / build (push) Has been skipped
Handle Changesets / Handle Changesets (push) Has been cancelled
Semgrep OSS scan / semgrep-oss (push) Has been cancelled

This commit is contained in:
wehub-resource-sync
2026-07-13 12:30:11 +08:00
commit 70bf21e064
5213 changed files with 731895 additions and 0 deletions
+127
View File
@@ -0,0 +1,127 @@
# Changesets
Every non-trivial change to the project - those that should appear in the changelog - must be captured in a "changeset".
We use the [`changesets`](https://github.com/changesets/changesets/blob/main/README.md) tool for creating changesets, publishing versions and updating the changelog.
## Creating a Changeset
```sh
pnpm changeset
```
1. Select which packages are affected by the change
2. Choose whether the version requires a major, minor, or patch release
3. Write a description of the change (see format below)
4. Include the generated changeset in your commit:
```sh
git add .changeset/*.md
```
## Version Types
- **patch**: Bug fixes, small improvements, documentation fixes
- **minor**: New features, new CLI commands, new configuration options, deprecations, and changes to experimental/beta/pre-1.0 features (including breaking changes to those features). When adding or changing experimental features, call this out explicitly in the changeset description.
- **major**: Breaking changes to stable features (when deprecations take effect, or functional breaking behavior is added). Note: breaking changes to experimental/beta features do NOT require a major version bump.
**Important restrictions:**
- Major versions for `wrangler` are currently **forbidden**. This rule will be removed when we are preparing for the next major release of `wrangler`.
- Major versions for other packages require strong justification
- If the change collects more analytics, it should be a minor even though there is no user-visible change.
## Changeset Message Format
```
<TITLE>
<BODY>
```
- **TITLE**: A single sentence with an imperative description of the change
- **BODY**: One or more paragraphs explaining the reason for the change and anything notable about the approach. Aim for more than one sentence but less than three paragraphs to keep it succinct and useful. Larger changes may warrant more detail.
### Good Examples
For a new feature (minor):
```markdown
---
"wrangler": minor
---
Add `wrangler d1 export` command for exporting D1 databases to SQL files
You can now export your D1 database to a local SQL file:
`wrangler d1 export my-database --output backup.sql`
This is useful for creating backups or migrating data between databases.
```
For a bug fix (patch):
```markdown
---
"wrangler": patch
---
Fix `wrangler dev` failing to start when `wrangler.toml` contains Unicode characters
Previously, projects with non-ASCII characters in configuration values would fail with "Invalid UTF-8 sequence". This is now handled correctly.
```
### Bad Examples (avoid these)
- "fix bug" - What bug? What was the symptom?
- "update dependency" - Which one? Why? Any user impact?
- "Add new feature" - What feature? How do you use it?
- "refactor" - Why does this warrant a release? What's the user impact?
## Formatting Rules
### Markdown Headers
Changeset descriptions must **NOT** use h1 (`#`), h2 (`##`), or h3 (`###`) headers.
The changelog uses h3 for section headers, so any headers in changeset content must be h4 (`####`) or smaller. This prevents formatting issues in the generated changelog.
### Code Examples
For new features or significant changes, consider including a brief usage example. Examples can be helpful for users to understand new functionality, but they are not mandatory—use your judgment based on how self-explanatory the change is.
When showing Wrangler configuration examples, use `wrangler.json` (with JSONC syntax for comments) rather than `wrangler.toml`.
## Multiple Changesets
If your PR makes multiple distinct user-facing changes, create separate changesets so each gets its own changelog entry. Don't lump unrelated changes together, and don't mix different types of changes (e.g., bug fix + new feature) in a single changeset.
## Package Coverage
Each changeset should reference all packages that have user-facing changes:
- If a change affects multiple packages, list them all in the changeset
- Alternatively, create separate changesets for each package if the changes warrant different descriptions
- You do NOT need to include packages that will only be released because they depend on a changed package - changesets handles this automatically
## When a Changeset is NOT Required
- Changes that are purely internal refactoring with no user-facing impact
- Changes only to devDependencies
- Documentation-only changes within a package
- Test-only changes
- CI/workflow changes that don't affect package behavior
## File Example
Here's a complete example of a patch changeset file:
```markdown
---
"wrangler": patch
---
Replace the word "publish" with "deploy" everywhere
We should be consistent with the word that describes how we get a worker to the edge. The command is `deploy`, so let's use that everywhere.
```
+7
View File
@@ -0,0 +1,7 @@
---
"miniflare": minor
---
Add `unsafeEvictDurableObject()` for targeted Durable Object eviction
This lets users verify how a Durable Object recovers after its instance is torn down.
+21
View File
@@ -0,0 +1,21 @@
{
"$schema": "https://unpkg.com/@changesets/config@1.6.2/schema.json",
"changelog": [
"@changesets/changelog-github",
{ "repo": "cloudflare/workers-sdk" }
],
"commit": false,
"linked": [],
"access": "public",
"baseBranch": "main",
"updateInternalDependencies": "patch",
"bumpVersionsWithWorkspaceProtocolOnly": true,
"___experimentalUnsafeOptions_WILL_CHANGE_IN_PATCH": {
"onlyUpdatePeerDependentsWhenOutOfRange": true
},
"ignore": [],
"privatePackages": {
"tag": true,
"version": true
}
}
@@ -0,0 +1,9 @@
---
"@cloudflare/local-explorer-ui": patch
---
Fix D1 schema editor tab not tracking unsaved changes
The schema editor tab (edit table / create table) now correctly marks the tab as dirty when there are unsaved schema changes. This shows the unsaved changes indicator on the tab, triggers the browser's leave guard when navigating away, and prompts for confirmation when closing the tab.
Additionally, column and constraint deletions now properly mark the schema as dirty. Previously, removing a column or constraint would filter the entry out of the state array entirely, causing the dirty-state check to miss the change.
+7
View File
@@ -0,0 +1,7 @@
---
"create-cloudflare": patch
---
Pass `--no-install` to `@tanstack/cli create` during scaffolding
Previously, the TanStack Start template did not pass `--no-install` to the framework CLI, causing dependencies to be installed twice: once by `@tanstack/cli create` and again by C3's own install step. This aligns the TanStack Start template with other framework templates that already skip the framework CLI's install.
+5
View File
@@ -0,0 +1,5 @@
---
"miniflare": minor
---
Allow `listDurableObjectIds()` to accept Durable Object class names as well as binding names.
+12
View File
@@ -0,0 +1,12 @@
---
"wrangler": minor
---
Add Durable Object eviction support to `createTestHarness`
You can now gracefully evict a running Durable Object by class name or binding name to verify how it recovers after its instance is torn down:
```ts
const worker = server.getWorker();
await worker.evictDurableObject("Counter", { name: "user-123" });
```
+7
View File
@@ -0,0 +1,7 @@
---
"@cloudflare/vite-plugin": patch
---
Fix load time crash on Node.js versions earlier than 22.15
The plugin eagerly imported `registerHooks` from `node:module`, which only exists on Node.js v22.15.0+. `registerHooks` is now read lazily, meaning that missing support is only surfaced when using `experimental.newConfig`.
@@ -0,0 +1,7 @@
---
"wrangler": patch
---
Improve the agent-facing `--force` guidance for Pages-to-Workers delegation
When an AI agent opts out of the Pages-to-Workers delegation by passing `--force` to `wrangler pages deploy` or `wrangler pages project create`, Wrangler now prints a notice at the end of a successful command explaining that `--force` only needs to be passed once: the project then exists, so subsequent commands are no longer delegated and do not need the flag.
@@ -0,0 +1,9 @@
---
"wrangler": minor
---
Remove support for service environments and the `legacy_env` configuration field
Service environments have been removed. Wrangler now always deploys each environment as its own Worker named `<name>-<environment>`, which matches the behaviour of the previous default (`legacy_env = true`). The `--legacy-env` CLI flag has been removed, and the `legacy_env` configuration field is no longer supported — including it in your configuration file will now raise an error.
Because `legacy_env = true` was already the default, removing the field will not change how your Worker is deployed. If you were relying on service environments (`legacy_env = false`), each environment will now be deployed as a standalone Worker instead of as an environment of a single Worker. See https://developers.cloudflare.com/workers/wrangler/environments/ for more information.
@@ -0,0 +1,7 @@
---
"wrangler": patch
---
Suggest similar commands when a typo is detected
When an unknown command or subcommand is entered, wrangler now suggests the closest matching command if one exists within a reasonable edit distance. For example, running `wrangler whoamio` will display `Did you mean "wrangler whoami"?`, and running `wrangler kv namespase` will display `Did you mean "wrangler kv namespace"?`.