refactor: merge deno_fetch into deno_web

[iuioiua]

Done in the same spirit as #31198.

Unblocks #31205.

[coderabbitai]

Walkthrough

The PR removes the ext/fetch crate and its workspace entries and replaces deno_fetch usages across the codebase with deno_web::fetch equivalents. It adds a new ext/web/fetch module implementing a full HTTP client (ReqBody/ResBody, Client, errors, ops, resources, DNS/proxy/file handlers) and updates JS imports and internal d.ts to reference ext:deno_web/*. Workspace Cargo.toml entries and runtime extension initialization were adjusted to initialize and expose the new deno_web fetch functionality.

Sequence Diagram(s)

sequenceDiagram
  autonumber
  participant JS as Runtime JS (global fetch)
  participant Op as Op Layer (op_fetch / op_fetch_send)
  participant ExtWeb as ext:deno_web (fetch ops)
  participant Client as deno_web::fetch::Client
  participant Backend as Network/File/DataURL

  JS->>Op: fetch(request)
  Op->>ExtWeb: validate & toInnerRequest
  ExtWeb->>Client: get_or_create_client / send(http::Request<ReqBody>)
  Client->>Backend: perform network/file/data fetch (async)
  Backend-->>Client: http::Response<ResBody> / error
  Client-->>ExtWeb: response (ResBody)
  ExtWeb->>Op: wrap into FetchResponseResource / stream body
  Op-->>JS: resolve Promise with Response (streaming)
  
  rect rgb(220,240,230)
    Note right of Client: retry, TLS, proxy, pooling, client certs
  end

Loading

Estimated code review effort

🎯 5 (Critical) | ⏱️ ~120 minutes

Points to focus review on:

• ext/web/fetch/mod.rs — large new public API surface (types, ops, resources, error mappings, client lifecycle).
• Removal of ext/fetch (lib.rs, internal.d.ts) — ensure all call sites migrated and no dangling imports/exports remain.
• Cross-crate type changes — many function signatures now use deno_web::fetch::ResBody/ReqBody/Client; verify compatibility and trait impls.
• Cargo.toml workspace edits and dependency swaps — confirm workspace membership, features, and build/init ordering.
• Runtime initialization changes (snapshot, web_worker, worker.rs) — verify deno_web::deno_web::init arity and state injection (fetch options).
• JS import path / internal.d.ts updates — ensure assets (20_headers.js, 22_body.js, 26_fetch.js, etc.) are present and import maps resolve.

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title 'refactor: merge deno_fetch into deno_web' accurately and concisely describes the main objective of the changeset, which consolidates the deno_fetch module into deno_web across the codebase.
Description check	✅ Passed	The PR description is terse but directly relates to the changeset. It references the merge of deno_fetch into deno_web and cites related PRs (#31198, #31205) that establish context for this refactoring.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (9)

ext/fetch/README.md (1)

3-4: Deprecation notice is clear; consider adding migration guidance (optional).

The deprecation message effectively communicates the transition to deno_web. For enhanced user experience, consider adding a brief note with migration guidance or a link to release notes/docs that explain how to update imports and usage patterns, especially for projects with existing deno_fetch dependencies.

Example enhancement:

 # deno_fetch
 
-This crate has been deprecated, use
-[deno_web](https://crates.io/crates/deno_web) instead.
+This crate has been deprecated, use
+[deno_web](https://crates.io/crates/deno_web) instead.
+
+For migration guidance, see the [deno_web fetch documentation](https://docs.rs/deno_web/latest/deno_web/fetch/).

ext/web/internal.d.ts (1)

3-4: Fetch-related internal typings are aligned, but FormData alias likely targets the wrong type

• Declaring domIterable.DomIterableMixin, the headers helpers, InnerBody, and the inner request/response conversion APIs under ext:deno_web/* matches how the JS modules are structured and gives the TS checker enough shape information for these internals.
• Inside the ext:deno_web/21_formdata.js declaration, type FormData = typeof FormData; makes the FormData alias refer to the constructor type, but functions like formDataToBlob(formData: FormData) and InnerBody.source: Blob | FormData conceptually operate on FormData instances, not the constructor.
• Unless this is intentional, consider changing that alias to the instance type (for example, type FormData = globalThis.FormData;) to keep parameter and field types accurate.

Please verify that the TS checker is happy with this alias when type-checking ext/web/21_formdata.js and its consumers; if you see confusing assignability errors around FormData, adjusting the alias as suggested should resolve them.

Also applies to: 144-147, 148-170, 172-182, 184-203, 205-236

cli/http_util.rs (1)

19-22: CLI HTTP client successfully migrated to deno_web::fetch

• HttpClientProvider now creates and caches deno_web::fetch::Client instances via create_http_client and CreateHttpClientOptions, keeping configuration (root cert store, unsafely_ignore_certificate_errors) identical to the previous deno_fetch-based setup.
• SendError and DownloadErrorKind::Fetch correctly wrap deno_web::fetch::ClientSendError, so error propagation through DownloadError remains intact.
• HttpClient::{get,post,post_json,send} using deno_web::fetch::ReqBody::{empty,full} and returning http::Response<ResBody>/http::Response<deno_web::fetch::ResBody> preserves the previous request/response behavior while aligning with the new body types.
• get_redirected_response and get_response_body_with_progress now operate on the new ResBody but retain the existing redirect, progress, and error-handling semantics, and the TLS-focused tests at the bottom of the file still exercise create_http_client via the new imports.

You might optionally import deno_web::fetch::{Client, ReqBody, ResBody} and use those aliases consistently (e.g., in get_redirected_response and RequestBuilder) to reduce repetition. Please also run the existing HTTP/TLS tests in this module to confirm the behavior is unchanged with the new client implementation.

Also applies to: 35-36, 46-47, 113-114, 179-181, 191-196, 199-200, 211-212, 231-232, 239-255, 326-331, 375-376, 443-445, 453-460

ext/web/fetch/mod.rs (3)

227-256: Prefer a scoped shared-borrow when cloning file_fetch_handler

In the "file" branch of op_fetch (around Line 408), you currently destructure Options from state.borrow_mut::<Options>() and then immediately call file_fetch_handler.fetch_file(state, &url) on the same OpState. While the compiler enforces safety, it would be clearer (and future‑proof against additional borrows inside fetch_file) to take a short‑lived shared borrow, clone the handler, and then drop the borrow before calling into it.

Consider refactoring along these lines:

-      let Options {
-        file_fetch_handler, ..
-      } = state.borrow_mut::<Options>();
-      let file_fetch_handler = file_fetch_handler.clone();
+      let file_fetch_handler = {
+        let options = state.borrow::<Options>();
+        options.file_fetch_handler.clone()
+      };
       let (future, maybe_cancel_handle) =
         file_fetch_handler.fetch_file(state, &url);

This avoids mixing a borrow of Options with a &mut OpState use in the same logical block and makes the aliasing story more obviously sound.

Also applies to: 408-421

---

308-375: Re‑check the single‑threaded invariant for ResourceToBodyAdapter

ResourceToBodyAdapter’s stream implementation and chunking logic look fine, but the unsafe impl Send / unsafe impl Sync rely entirely on the comment that it is “only used on a single-threaded executor”. Given this type now sits in the consolidated ext/web/fetch module and is used as a hyper::body::Body, it would be good to periodically validate that:

• This body never crosses into a multithreaded executor or thread‑pool context, and
• Future refactors to the HTTP client don’t change that assumption.

If there’s any chance this might be used across threads later, consider either removing the unsafe impls (and plumbing a non‑Send body where possible) or adding a stronger guard/doc comment explaining where this is instantiated.

---

813-887: HTTP client creation and TLS/proxy wiring mostly look good; avoid unwrap() on TLS keys

The op_fetch_custom_client + CreateHttpClientOptions + create_http_client pipeline is generally well‑designed:

• Proxy variants are validated against permissions (check_net_url, check_net, check_open, check_net_vsock) before use.
• TLS config is built via deno_tls::create_client_config with root store, CA certs, and unsafe options aggregated in one place.
• ALPN handling for proxy vs end‑server, http1/http2 flags, pool limits, idle timeouts, and local_address parsing are all coherently wired.
• CLI/JS‑level proxy options correctly override environment proxies by using proxies.prepend(intercept).

One minor concern is the use of:

client_cert_chain_and_key: tls_keys.take().try_into().unwrap(),

If try_into() can ever fail (for example due to invalid or already-consumed keys), this will panic and bring down the runtime instead of surfacing a structured HttpClientCreateError. If such failure is truly impossible by construction, a brief comment to that effect would make the invariant clearer; otherwise, mapping the error into a new HttpClientCreateError variant would be safer.

Everything else in this area looks consistent with the earlier deno_fetch behavior after consolidation.

Also applies to: 894-951, 953-1094

runtime/web_worker.rs (1)

523-541: Web workers now initialize fetch via deno_web::fetch::Options

Passing user_agent, root_cert_store_provider, unsafely_ignore_certificate_errors, and the FsFetchHandler into deno_web::deno_web::init cleanly hooks web workers into the unified fetch pipeline (including file: support) and matches the new ext/web::fetch API.

If the same fetch::Options block is duplicated in the main worker setup, consider a small shared helper to construct it so future tweaks (e.g., new hooks) stay in sync across runtimes.

cli/registry.rs (1)

90-92: Registry HTTP helpers now use deno_web::fetch::ResBody consistently

Updating parse_response and get_package to work with deno_web::fetch::ResBody brings the CLI registry code in line with the new fetch plumbing; the surrounding logic remains compatible.

http_util::body_to_string(response).await.unwrap() will still panic on body read failures. Not introduced by this PR, but if you revisit this path, consider propagating that error into an ApiError (or AnyError at the call site) instead of unwrapping.

Also applies to: 135-141

ext/kv/remote.rs (1)

172-197: Optional: align TLS key conversion with ext/web/fetch::create_client_from_options

The switch to deno_web::fetch::create_http_client and CreateHttpClientOptions looks correct: TLS, proxy, DNS, HTTP/2‑only, and ignore‑cert flags all map cleanly onto the new struct and match how ext/web/fetch builds clients.

One small robustness tweak you might consider is aligning client_cert_chain_and_key handling with ext/web/fetch::create_client_from_options, which uses unwrap_or_default() instead of unwrap() on the try_into() result. That would avoid a potential panic if the conversion ever fails and keep behavior consistent with the main fetch path.

-        client_cert_chain_and_key: options
-          .client_cert_chain_and_key
-          .clone()
-          .try_into()
-          .unwrap(),
+        client_cert_chain_and_key: options
+          .client_cert_chain_and_key
+          .clone()
+          .try_into()
+          .unwrap_or_default(),

It’s worth double‑checking that the TryInto target type here matches the one used in ext/web/fetch::CreateHttpClientOptions and that Default is implemented as expected.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 3c0f289 and 06a06ec.

⛔ Files ignored due to path filters (2)

• Cargo.lock is excluded by !**/*.lock
• tests/specs/run/wasm_streaming_panic_test/wasm_streaming_panic_test.js.out is excluded by !**/*.out

📒 Files selected for processing (59)

• Cargo.toml (0 hunks)
• cli/Cargo.toml (1 hunks)
• cli/http_util.rs (13 hunks)
• cli/registry.rs (2 hunks)
• cli/tools/publish/mod.rs (1 hunks)
• cli/tools/test/mod.rs (1 hunks)
• ext/cache/01_cache.js (1 hunks)
• ext/cache/Cargo.toml (1 hunks)
• ext/cache/lib.rs (1 hunks)
• ext/fetch/Cargo.toml (1 hunks)
• ext/fetch/README.md (1 hunks)
• ext/fetch/internal.d.ts (0 hunks)
• ext/fetch/lib.rs (0 hunks)
• ext/http/00_serve.ts (1 hunks)
• ext/http/01_http.js (1 hunks)
• ext/http/02_websocket.ts (1 hunks)
• ext/http/Cargo.toml (1 hunks)
• ext/http/lib.rs (2 hunks)
• ext/kv/Cargo.toml (1 hunks)
• ext/kv/lib.rs (1 hunks)
• ext/kv/remote.rs (3 hunks)
• ext/net/README.md (0 hunks)
• ext/node/Cargo.toml (1 hunks)
• ext/node/lib.rs (1 hunks)
• ext/node/ops/http.rs (3 hunks)
• ext/node/polyfills/http.ts (1 hunks)
• ext/node/polyfills/http2.ts (1 hunks)
• ext/node/polyfills/https.ts (1 hunks)
• ext/process/40_process.js (1 hunks)
• ext/web/22_body.js (1 hunks)
• ext/web/23_request.js (2 hunks)
• ext/web/23_response.js (2 hunks)
• ext/web/26_fetch.js (1 hunks)
• ext/web/27_eventsource.js (1 hunks)
• ext/web/Cargo.toml (1 hunks)
• ext/web/benches/encoding.rs (1 hunks)
• ext/web/benches/timers_ops.rs (1 hunks)
• ext/web/benches/url_ops.rs (1 hunks)
• ext/web/fetch/fs_fetch_handler.rs (1 hunks)
• ext/web/fetch/mod.rs (1 hunks)
• ext/web/fetch/tests.rs (2 hunks)
• ext/web/internal.d.ts (2 hunks)
• ext/web/lib.rs (4 hunks)
• ext/websocket/01_websocket.js (1 hunks)
• ext/websocket/02_websocketstream.js (1 hunks)
• ext/websocket/Cargo.toml (1 hunks)
• ext/websocket/lib.rs (4 hunks)
• runtime/Cargo.toml (0 hunks)
• runtime/js/90_deno_ns.js (1 hunks)
• runtime/js/98_global_scope_shared.js (1 hunks)
• runtime/js/99_main.js (1 hunks)
• runtime/lib.rs (0 hunks)
• runtime/ops/web_worker/sync_fetch.rs (3 hunks)
• runtime/shared.rs (0 hunks)
• runtime/snapshot.rs (0 hunks)
• runtime/snapshot_info.rs (1 hunks)
• runtime/web_worker.rs (1 hunks)
• runtime/worker.rs (2 hunks)
• tools/core_import_map.json (1 hunks)

💤 Files with no reviewable changes (8)

• ext/net/README.md
• runtime/snapshot.rs
• runtime/lib.rs
• Cargo.toml
• runtime/Cargo.toml
• runtime/shared.rs
• ext/fetch/lib.rs
• ext/fetch/internal.d.ts

🧰 Additional context used

🧬 Code graph analysis (12)

ext/node/ops/http.rs (2)

ext/web/fetch/mod.rs (1)

• extract_authority (1348-1374)

ext/web/fetch/proxy.rs (1)

• basic_auth (185-203)

cli/tools/publish/mod.rs (1)

ext/web/fetch/mod.rs (1)

• full (1290-1292)

runtime/web_worker.rs (3)

ext/web/fetch/mod.rs (1)

• user_agent (995-995)

cli/factory.rs (2)

• root_cert_store_provider (440-448)
• new (123-134)

cli/args/mod.rs (3)

• unsafely_ignore_certificate_errors (1220-1222)
• new (366-376)
• new (490-516)

runtime/worker.rs (4)

ext/web/fetch/mod.rs (1)

• user_agent (995-995)

cli/factory.rs (3)

• root_cert_store_provider (440-448)
• new (123-134)
• resolver (682-685)

cli/lib/worker.rs (1)

• new (534-578)

ext/node/ops/dns.rs (1)

• resolver (43-48)

ext/kv/remote.rs (2)

ext/web/fetch/mod.rs (2)

• full (1290-1292)
• create_http_client (955-1094)

cli/tsc/dts/lib.deno.ns.d.ts (1)

• CreateHttpClientOptions (6305-6336)

ext/websocket/lib.rs (1)

ext/web/fetch/mod.rs (1)

• get_or_create_client_from_state (265-276)

ext/web/lib.rs (2)

ext/web/26_fetch.js (1)

• op_fetch (174-182)

ext/web/fetch/mod.rs (5)

• op_fetch (381-555)
• op_fetch_send (575-635)
• op_utf8_to_byte_string (1098-1100)
• op_fetch_custom_client (812-892)
• op_fetch_promise_is_settled (1377-1379)

runtime/ops/web_worker/sync_fetch.rs (1)

ext/web/fetch/mod.rs (3)

• create_client_from_options (278-306)
• req (1403-1403)
• empty (1294-1296)

ext/web/fetch/tests.rs (1)

ext/web/fetch/mod.rs (1)

• empty (1294-1296)

ext/web/internal.d.ts (5)

ext/web/23_response.js (7)

• list (223-223)
• headers (205-205)
• headers (490-492)
• body (115-115)
• status (484-486)
• headerList (110-113)
• response (513-513)

ext/web/20_headers.js (3)

• list (148-148)
• headers (499-499)
• entries (166-166)

ext/web/22_body.js (4)

• body (501-501)
• boundary (399-399)
• entries (408-408)
• stream (433-433)

ext/web/26_fetch.js (5)

• body (127-127)
• body (156-156)
• stream (155-155)
• response (211-222)
• response (513-513)

ext/web/21_formdata.js (2)

• boundary (308-315)
• entries (362-362)

cli/http_util.rs (2)

cli/tsc/dts/lib.deno.ns.d.ts (1)

• CreateHttpClientOptions (6305-6336)

ext/web/fetch/mod.rs (8)

• create_http_client (955-1094)
• from (215-224)
• default (129-141)
• default (672-675)
• default (911-926)
• url (427-429)
• empty (1294-1296)
• full (1290-1292)

ext/web/fetch/mod.rs (4)

ext/kv/remote.rs (5)

• bytes (110-112)
• stream (113-117)
• root_cert_store (37-42)
• new (50-52)
• clone (60-64)

ext/web/fetch/fs_fetch_handler.rs (1)

• fetch_file (31-88)

ext/web/fetch/proxy.rs (10)

• parse (258-341)
• parse (967-969)
• basic_auth (185-203)
• val (279-279)
• from_env (140-183)
• from_env (384-390)
• intercept (500-502)
• intercept (519-538)
• all (212-217)
• host (443-443)

ext/tls/lib.rs (1)

• create_client_config (286-361)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (11)

• GitHub Check: test debug linux-aarch64
• GitHub Check: test debug windows-x86_64
• GitHub Check: test debug linux-x86_64
• GitHub Check: test release linux-x86_64
• GitHub Check: test debug macos-aarch64
• GitHub Check: test release macos-x86_64
• GitHub Check: test debug macos-x86_64
• GitHub Check: build libs
• GitHub Check: lint debug macos-x86_64
• GitHub Check: lint debug windows-x86_64
• GitHub Check: lint debug linux-x86_64

🔇 Additional comments (49)

ext/web/27_eventsource.js (1)

36-42: Import path migration verified and approved.

The updated import paths all resolve correctly—all three modules (ext/web/20_headers.js, ext/web/23_request.js, ext/web/26_fetch.js) exist in the expected locations. The changes align with the PR objective of merging deno_fetch into deno_web, and all imported functions are actively used in the EventSource implementation.

ext/websocket/Cargo.toml (1)

23-23: Dependency migration from deno_fetch to deno_web is correct and complete.

Verification confirms that all source code imports in the websocket crate have been properly updated. The crate now imports four types and utilities from deno_web::fetch (ClientConnectError, HttpClientCreateError, HttpClientResource, and get_or_create_client_from_state), and no lingering references to deno_fetch remain. The Cargo.toml change is fully aligned with the source code implementation.

ext/cache/01_cache.js (1)

22-29: Verification confirmed - import migration is complete and correct.

All three imported symbols (toInnerRequest, toInnerResponse, getHeader) are properly exported from their new module locations in ext:deno_web, and all usages throughout the file are consistent with the import statements. No remaining references to ext:deno_fetch exist in this file.

ext/process/40_process.js (1)

31-31: LGTM!

The import path update from ext:deno_fetch/22_body.js to ext:deno_web/22_body.js is correct and aligns with the PR's objective to migrate fetch functionality into deno_web.

cli/Cargo.toml (1)

96-96: LGTM!

Adding deno_web as a workspace dependency is correct for the migration. This provides the CLI with access to the fetch functionality now consolidated in deno_web.

ext/web/22_body.js (1)

50-50: LGTM!

The import path update correctly reflects the migration of FormData utilities from ext:deno_fetch/21_formdata.js to ext:deno_web/21_formdata.js.

ext/node/polyfills/https.ts (1)

15-15: LGTM!

The import path update from ext:deno_fetch/22_http_client.js to ext:deno_web/22_http_client.js correctly reflects the migration. The createHttpClient function usage remains unchanged.

ext/cache/lib.rs (1)

101-101: LGTM!

The extension dependency update from deno_fetch to deno_web is correct and aligns with the migration objectives.

ext/kv/lib.rs (1)

38-38: LGTM!

Adding the public re-export pub use deno_web; correctly makes the deno_web crate accessible to consumers of the ext/kv module, supporting the fetch functionality migration.

ext/web/fetch/fs_fetch_handler.rs (1)

21-23: LGTM!

The import path updates correctly reflect the reorganization of fetch-related types into the crate::fetch module namespace, maintaining consistency with the consolidated fetch structure.

cli/tools/test/mod.rs (1)

835-835: LGTM!

The type reference update from deno_runtime::deno_fetch::Client to deno_web::fetch::Client correctly reflects the migration while preserving the test isolation logic that ensures each test gets a fresh connection pool.

ext/http/Cargo.toml (1)

37-37: LGTM! Dependency migration aligned with PR objective.

The removal of deno_fetch and reliance on deno_web is consistent with merging fetch functionality into deno_web.

ext/web/benches/url_ops.rs (1)

23-28: LGTM! Consistent with other benchmark files.

The fourth argument addition matches the pattern used in other benchmark files.

runtime/js/98_global_scope_shared.js (1)

16-27: LGTM! Import paths consistently updated.

All web API imports have been correctly migrated from ext:deno_fetch to ext:deno_web.

ext/fetch/Cargo.toml (1)

5-11: LGTM! Appropriate deprecation of deno_fetch package.

The package is correctly marked as deprecated with a clear message directing users to deno_web. The version bump and removal of dependencies are appropriate for this deprecation.

ext/web/benches/timers_ops.rs (1)

29-34: LGTM! Consistent with other benchmark files.

The fourth argument addition matches the initialization pattern used throughout the codebase.

ext/web/benches/encoding.rs (1)

30-35: Initialization pattern verified as consistent.

The verification confirms that all deno_web::deno_web::init::<deno_web::InMemoryBroadcastChannel> calls consistently use a four-argument pattern. The change in encoding.rs is consistent with url_ops.rs and timers_ops.rs (all using: Default::default(), None, Default::default(), Default::default()). The variation in snapshot_info.rs appears intentional for that specific module context.

ext/web/26_fetch.js (1)

50-59: Migration verification complete—all runtime import paths correctly migrated.

The script successfully confirmed no ext:deno_fetch import paths remain in JavaScript runtime code. The file ext/web/26_fetch.js and all related modules correctly use ext:deno_web/... imports as shown in the code snippet.

runtime/snapshot_info.rs (1)

20-25: Verification complete: extension initialization order is correct.

The removal of deno_fetch::deno_fetch::init has been consistently applied across all four runtime files. Extension ordering is maintained:

• runtime/snapshot_info.rs: telemetry → webidl → web → webgpu → canvas → cache → websocket → webstorage
• runtime/web_worker.rs: telemetry → webidl → web → (continues)
• runtime/worker.rs: webidl → web → webgpu → canvas
• runtime/snapshot.rs: telemetry → webidl → web → webgpu → canvas

No active deno_fetch references exist in Rust runtime code; only TypeScript type definitions and build configuration mention it (expected for compatibility). The migration to consolidate fetch functionality into deno_web is complete and correct.

ext/web/fetch/tests.rs (1)

17-22: Fetch DNS and request body wiring correctly follow new deno_web::fetch layout

• Importing crate::fetch::dns and using dns::Resolver in rust_test_client_with_resolver is consistent with the fetch module move.
• Updating the TLS fixtures to "../../tls/testdata/..." matches the new nesting of ext/web/fetch/tests.rs under ext/web/.
• Switching to crate::fetch::ReqBody::empty() aligns the test with the new request body type exposed from ext/web/fetch::ReqBody.

Also applies to: 132-135

ext/web/Cargo.toml (1)

18-27: New deno_web dependencies match migrated fetch responsibilities

The added dependencies (HTTP stack, TLS, DNS, proxy support, and test-only fast-socks5/rustls) are exactly what the fetch client needs and are correctly marked as workspace = true (plus target-gated tokio-vsock). This cleanly absorbs deno_fetch’s former dependency surface into deno_web.

Also applies to: 29-32, 34-54, 57-59, 63-64

ext/cache/Cargo.toml (1)

24-24: deno_cache now correctly depends on deno_web

Adding deno_web as a workspace dependency is consistent with moving fetch primitives there and avoids any lingering reliance on deno_fetch.

ext/websocket/lib.rs (1)

29-33: WebSocket handshake now cleanly reuses deno_web::fetch client and errors

• Importing ClientConnectError, HttpClientCreateError, HttpClientResource, and get_or_create_client_from_state from deno_web::fetch keeps all HTTP client concerns under the consolidated fetch module.
• HandshakeError::Connect(#[from] ClientConnectError) and WebsocketError::ClientCreate(#[from] HttpClientCreateError) preserve the previous error mapping while swapping to the new types.
• Updating handshake_websocket, handshake_http1, and handshake_http2 to take deno_web::fetch::Client is a straightforward type swap; their internal logic and use of SocketUse remain unchanged.
• op_ws_create still respects a passed-in HTTP client resource via HttpClientResource and otherwise falls back to get_or_create_client_from_state, so connection reuse and allow_host semantics are preserved.
• Changing the extension deps to [deno_web, deno_webidl] matches the new source of the HTTP client and removes the need for a separate deno_fetch extension.

Please ensure the deno_web::fetch client still exposes connect, inject_common_headers, and HttpClientResource { client, allow_host } with the same semantics as before. This should be covered by the existing websocket tests, so a focused websocket test run is a good sanity check.

Also applies to: 93-103, 203-246, 248-304, 306-344, 400-427, 848-866

tools/core_import_map.json (1)

513-519: Import map correctly re-homes fetch JS under ext:deno_web

Remapping the fetch JS modules to "ext:deno_web/20_headers.js" … "ext:deno_web/26_fetch.js" while keeping the physical paths under ../ext/fetch/ is a reasonable transitional step and matches the new TypeScript declarations in ext/web/internal.d.ts.

runtime/worker.rs (1)

200-201: Runtime now configures deno_web fetch directly with DNS/TLS options

• Adding fetch_dns_resolver: deno_web::fetch::dns::Resolver to WorkerServiceOptions and passing it into deno_web::fetch::Options makes the worker’s fetch stack explicitly configurable and aligns with how CreateHttpClientOptions defaults dns::Resolver.
• The rest of the Options (user agent, root cert store provider, unsafely_ignore_certificate_errors, and file_fetch_handler: FsFetchHandler) mirror the previous deno_fetch-side configuration, so behavior for network, TLS, and file:// fetches should be preserved.

Please double-check that deno_web::fetch::dns::Resolver is either Copy or you never use services after moving this field out; otherwise, consider using resolver: services.fetch_dns_resolver.clone() here to avoid partial-move issues. A quick cargo check across runtime should validate this.

Also applies to: 531-549

ext/web/fetch/mod.rs (3)

95-142: Options wiring and defaults look consistent

The Options struct cleanly encapsulates user agent, TLS roots, proxy, hooks, file handler, and DNS resolver, and Default plus root_cert_store() behavior matches the expected fetch configuration model. No issues spotted here.

---

376-555: HTTP/HTTPS branch in op_fetch aligns with fetch/network expectations

The main HTTP/HTTPS path in op_fetch looks solid:

• Net permissions are checked via PermissionsContainer::check_net_url before constructing the URI.
• Username/password in the URL are stripped via extract_authority and mapped into an Authorization header, avoiding credentials leaking in the request URI.
• Content-Length is set from known body size (buffer or sized resource) and explicitly forced to 0 for POST/PUT with no body, and conflicting user Content-Length headers are ignored.
• Range requests force Accept-Encoding: identity in line with the spec, and a request_builder_hook is provided for final customization.
• The cancellation path via CancelHandle and or_cancel wiring into FetchRequestResource is coherent.

This all matches the expected semantics for Deno’s fetch implementation after the move.

---

573-635: op_fetch_send’s error propagation and response resource setup look correct

The logic in op_fetch_send to:

• Unwrap the single outstanding FetchRequestResource (Rc::try_unwrap),
• Distinguish between a canceled request and a genuine FetchError,
• Attempt to surface a nested error cause into FetchResponse.error for JS reconstruction, and
• Register a FetchResponseResource with a correct content_length hint

appears consistent and well‑structured. The behavior should closely mirror the previous deno_fetch implementation while adding better error introspection.

ext/kv/Cargo.toml (1)

16-42: Dependency switch to deno_web verified as complete

The addition of deno_web.workspace = true in ext/kv/Cargo.toml is appropriate and the migration is clean—no lingering deno_fetch references remain in the directory.

runtime/js/99_main.js (1)

60-71: Import refactoring verified—fetch module correctly exports handleWasmStreaming

The new ext:deno_web/26_fetch.js properly exports handleWasmStreaming (line 608), the function definition exists (line 545), and runtime/js/99_main.js correctly uses it at line 400. All old deno_fetch module imports have been removed.

ext/websocket/02_websocketstream.js (1)

41-45: Headers helpers import verified; all required functions exported

Verified that ext:deno_web/20_headers.js exports all three required functions (fillHeaders, headerListFromHeaders, headersFromHeaderList) with unchanged signatures. The import refactoring in 02_websocketstream.js is correct.

runtime/js/90_deno_ns.js (1)

11-13: HttpClient wiring migration verified and correct

All components of the migration from deno_fetch to deno_web are in place and functioning correctly:

• ext/web/22_http_client.js properly exports both createHttpClient (line 31) and HttpClient class (line 103)
• The import in 90_deno_ns.js (line 12) correctly references the new module path
• Namespace wiring at lines 168–169 correctly exposes these symbols on the Deno object
• No remnants of the old deno_fetch path remain in the runtime

ext/node/Cargo.toml (1)

43-43: LGTM: Workspace dependency addition aligns with the migration.

The addition of deno_web.workspace = true correctly establishes the dependency needed for the deno_fetch to deno_web migration.

ext/http/01_http.js (1)

34-45: LGTM: Import paths correctly updated to deno_web.

The import sources for InnerBody, ResponsePrototype, toInnerResponse, abortRequest, fromInnerRequest, and newInnerRequest have been consistently migrated from ext:deno_fetch to ext:deno_web without any changes to the imported symbols or logic.

ext/node/lib.rs (1)

34-34: LGTM: Public re-export supports the migration.

The addition of pub use deno_web; expands the public API surface to include deno_web, which is consistent with the broader migration strategy and the dependency addition in Cargo.toml.

ext/node/polyfills/http2.ts (1)

23-23: LGTM: Import path correctly migrated.

The toInnerRequest import has been properly updated from ext:deno_fetch/23_request.js to ext:deno_web/23_request.js, maintaining consistency with the broader migration.

ext/websocket/01_websocket.js (1)

74-75: LGTM: Header and HTTP client imports migrated correctly.

Both import statements have been properly updated to use ext:deno_web paths while preserving all imported symbols (fillHeaders, headerListFromHeaders, headersFromHeaderList, HttpClientPrototype).

ext/http/02_websocket.ts (1)

15-19: LGTM: Request and response imports migrated correctly.

The import paths for toInnerRequest, fromInnerResponse, and newInnerResponse have been consistently updated from ext:deno_fetch to ext:deno_web without any changes to the imported symbols.

cli/tools/publish/mod.rs (1)

925-925: LGTM: ReqBody reference correctly updated.

The module path has been properly updated from deno_fetch::ReqBody::full to deno_web::fetch::ReqBody::full, reflecting the new module structure. The function call and its context remain unchanged.

ext/web/23_response.js (1)

22-32: LGTM: Body and header imports migrated correctly.

The import paths for extractBody, mixinBody, and the header utilities (fillHeaders, getDecodeSplitHeader, guardFromHeaders, headerListFromHeaders, headersFromHeaderList) have been consistently updated to use ext:deno_web paths, completing the internal migration.

ext/node/ops/http.rs (1)

44-46: Node HTTP now correctly reuses deno_web::fetch types and helpers

Imports of FetchCancelHandle, FetchReturn, ResBody and the switch to deno_web::fetch::extract_authority / proxy::basic_auth align the Node HTTP client with the shared fetch implementation while preserving existing behavior and cancellation semantics. No issues spotted.

Also applies to: 181-182, 241-245, 482-503

ext/http/00_serve.ts (1)

58-70: Serve internals correctly switched to ext:deno_web request/response/body modules

The updated imports for InnerBody, fromInnerResponse/toInnerResponse, and abortRequest route Deno.serve through the unified deno_web fetch implementation without changing behavior.

ext/node/polyfills/http.ts (1)

72-74: Node HTTP polyfill now uses deno_web headers and Response

Pointing headersEntries and Response at ext:deno_web keeps the Node HTTP polyfill aligned with the consolidated fetch/web stack while preserving existing header and response handling semantics.

ext/http/lib.rs (1)

142-146: deno_http extension dependency list correctly drops deno_fetch

Switching the deps arrays to [deno_web, deno_net, deno_websocket] matches the move of fetch functionality into deno_web and keeps the HTTP extension’s JS modules (like 00_serve.ts) correctly sourced.

Also applies to: 193-196

ext/web/23_request.js (1)

31-43: Request module correctly switched to ext:deno_web body/headers/http-client helpers

Routing extractBody/mixinBody, header utilities, and HttpClientPrototype through ext:deno_web keeps Request and the non-standard client option in sync with the consolidated fetch stack, without altering validation or cloning behavior.

ext/web/lib.rs (1)

8-9: deno_web now owns fetch (module, ops, JS assets, and options) coherently

Exporting the fetch module, registering its ops, adding the corresponding JS modules (headers/body/request/response/fetch/eventsource), and threading fetch_options: fetch::Options into op state cleanly consolidates fetch under deno_web and matches how ext/web/fetch expects to be configured. The wiring in this file looks consistent.

Also applies to: 114-119, 142-150, 153-168

ext/kv/remote.rs (1)

78-79: FetchClient/FetchResponse migration to deno_web::fetch looks consistent

Wrapping deno_web::fetch::Client and ResBody in FetchClient/FetchResponse, and switching to deno_web::fetch::ReqBody::full in RemoteTransport::post, keeps the existing RemoteTransport / RemoteResponse surface and BodyExt-based consumption semantics intact. Assuming deno_web::fetch::ResBody continues to implement the same http_body traits (as it does in ext/web/fetch), this should be a drop‑in replacement with no behavioral change.

If you want an extra check, you can run the existing KV remote tests to confirm there’s no regression in streaming/collect behavior for responses.

Also applies to: 89-106

runtime/ops/web_worker/sync_fetch.rs (2)

10-11: Imports correctly updated to deno_web::fetch

Switching the imports to deno_web::fetch::FetchError and deno_web::fetch::data_url::DataUrl matches the new fetch module structure and keeps the rest of the file’s usages (FetchError::ClientCreate, DataUrl::process, etc.) coherent.

Please confirm that deno_web::fetch::FetchError still exposes the same constructors/variants (ClientCreate, ClientSend, DataUrl, Base64, BlobNotFound) expected by this file.

---

98-101: Migration to deno_web::fetch::Options verified across all initialization and usage sites

The verification confirms the migration is complete and correctly implemented:

• All references to the old deno_fetch::Options type have been removed from the codebase
• Both worker initialization paths (runtime/worker.rs and runtime/web_worker.rs) properly pass deno_web::fetch::Options to the deno_web extension
• The sync_fetch op at runtime/ops/web_worker/sync_fetch.rs:98 successfully borrows deno_web::fetch::Options from state
• The request body construction at lines 132-137 correctly uses deno_web::fetch::ReqBody::empty()

The architecture is sound: Options are passed to extension initialization functions, which handle storing them in OpState internally, allowing subsequent ops to borrow them as needed.

[iuioiua]

PTAL @bartlomieju