[pull] main from cloudflare:main

.github/workflows/vite-plugin-playgrounds.yml

@@ -23,12 +23,12 @@ jobs:
       fail-fast: false
       matrix:
         os: [ubuntu-latest, macos-latest, windows-latest]
-        vite: ["vite-7"]
+        vite: ["vite-8"]
         include:
           - os: ubuntu-latest
             vite: "vite-6"
           - os: ubuntu-latest
-            vite: vite-8
+            vite: "vite-7"
     runs-on: ${{ matrix.os }}
     steps:
       - name: Checkout Repo
@@ -59,11 +59,11 @@ jobs:
       - name: Downgrade to Vite 6
         if: steps.changes.outputs.everything_but_markdown == 'true' && matrix.vite == 'vite-6'
         run: |
-          pnpm update -r --no-save vite@6.4.1
-      - name: Upgrade to Vite 8
-        if: steps.changes.outputs.everything_but_markdown == 'true' && matrix.vite == 'vite-8'
+          pnpm update -r --no-save vite@^6.1.0
+      - name: Downgrade to Vite 7
+        if: steps.changes.outputs.everything_but_markdown == 'true' && matrix.vite == 'vite-7'
         run: |
-          pnpm update -r --no-save vite@^8.0.0
+          pnpm update -r --no-save vite@^7.0.0
       - name: Run dev playground tests
         if: steps.changes.outputs.everything_but_markdown == 'true'
         # We use `--only` to prevent TurboRepo from rebuilding dependencies

CONTRIBUTING.md

@@ -176,7 +176,6 @@ For TypeScript to work properly in the Monorepo the version used in VSCode must
 3. In the command palette, type "Select TypeScript Version" and select the command with the same name that appears in the list.
 
 4. A submenu will appear with a list of available TypeScript versions. Choose the desired version you want to use for this project. If you have multiple versions installed, they will be listed here.
-
    - Selecting "Use Workspace Version" will use the version of TypeScript installed in the project's `node_modules` directory.
 
 5. After selecting the TypeScript version, VSCode will reload the workspace using the chosen version.
@@ -272,7 +271,6 @@ Changes should be committed to a new local branch, which then gets pushed to you
   ```
 
 - Stage files to include in a commit
-
   - Use [VS Code](https://code.visualstudio.com/docs/editor/versioncontrol#_git-support)
   - Or add and commit files via the command line
 

fixtures/vitest-pool-workers-examples/README.md

@@ -2,22 +2,22 @@
 
 This directory contains example projects tested with `@cloudflare/vitest-pool-workers`. It aims to provide the building blocks for you to write tests for your own Workers. Note the examples in this directory define `singleWorker: true` options. We recommend you enable this option if you have lots of small test files. Isolated storage is enabled by default meaning writes performed in each test are automatically undone when the test finishes.
 
-| Directory                                                                          | Overview                                                  |
-| ---------------------------------------------------------------------------------- | --------------------------------------------------------- |
-| [✅ basics-unit-integration-self](basics-unit-integration-self)                    | Basic unit tests and integration tests using `SELF`       |
-| [⚠️ basics-integration-auxiliary](basics-integration-auxiliary)                    | Basic integration tests using an auxiliary worker[^1]     |
+| Directory                                                                         | Overview                                                  |
+| --------------------------------------------------------------------------------- | --------------------------------------------------------- |
+| [✅ basics-unit-integration-self](basics-unit-integration-self)                   | Basic unit tests and integration tests using `SELF`       |
+| [⚠️ basics-integration-auxiliary](basics-integration-auxiliary)                   | Basic integration tests using an auxiliary worker[^1]     |
 | [⚡️ pages-functions-unit-integration-self](pages-functions-unit-integration-self) | Functions unit tests and integration tests using `SELF`   |
-| [📦 kv-r2-caches](kv-r2-caches)                                                    | Isolated tests using KV, R2 and the Cache API             |
-| [📚 d1](d1)                                                                        | Isolated tests using D1 with migrations                   |
-| [📌 durable-objects](durable-objects)                                              | Isolated tests using Durable Objects with direct access   |
-| [🔁 workflows](workflows)                                                          | Tests using Workflows                                     |
-| [🚥 queues](queues)                                                                | Tests using Queue producers and consumers                 |
-| [🚰 pipelines](pipelines)                                                          | Tests using Pipelines                                     |
-| [🚀 hyperdrive](hyperdrive)                                                        | Tests using Hyperdrive with a Vitest managed TCP server   |
-| [🤹 request-mocking](request-mocking)                                              | Tests using declarative/imperative outbound request mocks |
-| [🔌 multiple-workers](multiple-workers)                                            | Tests using multiple auxiliary workers and request mocks  |
-| [⚙️ web-assembly](web-assembly)                                                    | Tests importing WebAssembly modules                       |
-| [🤯 rpc](rpc)                                                                      | Tests using named entrypoints, Durable Objects and RPC    |
-| [🤷 misc](misc)                                                                    | Tests for other assorted Vitest features                  |
+| [📦 kv-r2-caches](kv-r2-caches)                                                   | Isolated tests using KV, R2 and the Cache API             |
+| [📚 d1](d1)                                                                       | Isolated tests using D1 with migrations                   |
+| [📌 durable-objects](durable-objects)                                             | Isolated tests using Durable Objects with direct access   |
+| [🔁 workflows](workflows)                                                         | Tests using Workflows                                     |
+| [🚥 queues](queues)                                                               | Tests using Queue producers and consumers                 |
+| [🚰 pipelines](pipelines)                                                         | Tests using Pipelines                                     |
+| [🚀 hyperdrive](hyperdrive)                                                       | Tests using Hyperdrive with a Vitest managed TCP server   |
+| [🤹 request-mocking](request-mocking)                                             | Tests using declarative/imperative outbound request mocks |
+| [🔌 multiple-workers](multiple-workers)                                           | Tests using multiple auxiliary workers and request mocks  |
+| [⚙️ web-assembly](web-assembly)                                                   | Tests importing WebAssembly modules                       |
+| [🤯 rpc](rpc)                                                                     | Tests using named entrypoints, Durable Objects and RPC    |
+| [🤷 misc](misc)                                                                   | Tests for other assorted Vitest features                  |
 
 [^1]: When using `SELF` for integration tests, your worker code runs in the same context as the test runner. This means you can use global mocks to control your worker, but also means your worker uses the same subtly different module resolution behaviour provided by Vite. Usually this isn't a problem, but if you'd like to run your worker in a fresh environment that's as close to production as possible, using an auxiliary worker may be a good idea. Note this prevents global mocks from controlling your worker, and requires you to build your worker ahead-of-time. This means your tests won't re-run automatically if you change your worker's source code, but could be useful if you have a complicated build process (e.g. full-stack framework).

fixtures/vitest-pool-workers-examples/misc/test/defines.test.ts

@@ -9,5 +9,5 @@ it("replaces defines from wrangler.toml", async ({ expect }) => {
 it("replaces defines from vitest.config.mts", async ({ expect }) => {
 	expect(CONFIG_DEFINED_THING).toBe("thing");
 	expect(CONFIG_NESTED.DEFINED.THING).toStrictEqual([1, 2, 3]);
-	expect(CONFIG_NESTED.DEFINED.THING).toBe(CONFIG_NESTED.DEFINED.THING);
+	// Note that, unlike ESBuild, Oxc does not share object references when using `define` (https://oxc.rs/docs/guide/usage/transformer/global-variable-replacement#define)
 });

fixtures/vitest-pool-workers-examples/package.json

@@ -29,7 +29,7 @@
 		"stripe": "^20.0.0",
 		"toucan-js": "4.0.0",
 		"typescript": "catalog:default",
-		"vite": "catalog:default",
+		"vite": "catalog:vitest-4",
 		"vitest": "catalog:default",
 		"wrangler": "workspace:*"
 	},

package.json

@@ -44,7 +44,7 @@
 		"esbuild": "catalog:default",
 		"esbuild-register": "^3.5.0",
 		"jsonc-parser": "catalog:default",
-		"prettier": "^3.2.5",
+		"prettier": "^3.8.1",
 		"prettier-plugin-packagejson": "^2.2.18",
 		"prettier-plugin-tailwindcss": "^0.7.2",
 		"tree-kill": "^1.2.2",
@@ -78,8 +78,8 @@
 			"@cloudflare/elements>@types/react": "^18",
 			"@types/node": "$@types/node",
 			"@types/node>undici-types": "catalog:default",
-			"vitest@4>vite": "catalog:vite-plugin",
-			"vitest@3>vite": "^5.0.0"
+			"vitest@4>vite": "catalog:vitest-4",
+			"vitest@3>vite": "catalog:vitest-3"
 		},
 		"patchedDependencies": {
 			"@cloudflare/component-listbox@1.10.6": "patches/@cloudflare__component-listbox@1.10.6.patch",

packages/chrome-devtools-patches/CHANGELOG.md

@@ -1,5 +1,15 @@
 # @cloudflare/chrome-devtools-patches
 
+## 0.1.5
+
+### Patch Changes
+
+- [#12928](https://github.com/cloudflare/workers-sdk/pull/12928) [`81ee98e`](https://github.com/cloudflare/workers-sdk/commit/81ee98e6a0c6be879757289ef6e34e1559d6ee2a) Thanks [@petebacondarwin](https://github.com/petebacondarwin)! - Migrate chrome-devtools-patches deployment from Cloudflare Pages to Workers + Assets
+
+  The DevTools frontend is now deployed as a Cloudflare Workers + Assets project instead of a Cloudflare Pages project. This uses `wrangler deploy` for production deployments and `wrangler versions upload` for PR preview deployments.
+
+  The inspector proxy origin allowlists in both wrangler and miniflare have been updated to accept connections from the new `workers.dev` domain patterns, while retaining the legacy `pages.dev` patterns for backward compatibility.
+
 ## 0.1.4
 
 ### Patch Changes
@@ -29,7 +39,6 @@
 ### Minor Changes
 
 - [#7137](https://github.com/cloudflare/workers-sdk/pull/7137) [`1b195bd`](https://github.com/cloudflare/workers-sdk/commit/1b195bd09aef282a8a205d341579cdb7e3755d89) Thanks [@andyjessop](https://github.com/andyjessop)! - feat: update devtools patches for release
-
   - rebases patches on top of latest devtools head
   - removes CPU profiling tab
   - adds performance tab

packages/chrome-devtools-patches/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "@cloudflare/chrome-devtools-patches",
-	"version": "0.1.4",
+	"version": "0.1.5",
 	"private": true,
 	"description": "Chrome Devtools hosted for easy use with Workers tooling and applications (Wrangler, Playground, Quick Editor).",
 	"homepage": "https://github.com/cloudflare/workers-sdk#readme",

packages/containers-shared/src/utils.ts

@@ -267,7 +267,7 @@ export function resolveDockerHost(dockerPath: string): string {
 export const getDockerHostFromEnv = (): string => {
 	const fromEnv = process.env.WRANGLER_DOCKER_HOST ?? process.env.DOCKER_HOST;
 
-	return fromEnv ?? process.platform === "win32"
+	return (fromEnv ?? process.platform === "win32")
 		? "//./pipe/docker_engine"
 		: "unix:///var/run/docker.sock";
 };