Enable the new module registry by default from 2026-11-17 by irvinebroque · Pull Request #7799 · cloudflare/workerd

irvinebroque · 2026-10-17T15:23:50Z

JavaScript Workers currently require new_module_registry to use URL-based module resolution, import.meta, validated import attributes, and the new require(esm) semantics. Make the registry the default for compatibility dates on or after 2026-11-17. Earlier dates retain their current behavior, legacy_module_registry remains an opt-out, and Python Workers retain the legacy registry.

Remove the standalone server requirement for --experimental so Workers using the default registry can start normally. Module fallback remains experimental and requires --experimental with either registry.

The companion docs PR includes an October 17 advance announcement, an example, migration guidance, and a link to the September 2026 blog announcement.

Regression coverage checks the November 17 boundary, early opt-in, the legacy opt-out, Python exclusion, startup without experimental mode, and module fallback rejection without experimental mode for both registries.

Validation: the focused C++ November 16/17 boundary test passed against the production compatibility-date library using a temporary lightweight harness, including early opt-in and opt-out, plus Python exclusion. Schema generation, date consistency, edited-line formatting preservation, and git diff --check passed. JavaScript syntax checking passed. Full Bazel and server integration suites were not completed locally.

Compatibility decision: use the new JavaScript module registry for compatibility dates on or after 2026-11-01, including import.meta, URL-based resolution, import attribute validation, and Node.js require(esm) semantics. Earlier dates retain the opt-in behavior and legacy_module_registry remains an opt-out. Python Workers retain the legacy registry. Allow the scheduled Sunday date in the existing weekday guard. Remove the standalone server experimental-mode restriction so date-enabled Workers can start without --experimental.

jasnell

the default on date may need to be pushed out another week or two

Compatibility decision: use the new JavaScript module registry for compatibility dates on or after 2026-11-08, one week after the previously scheduled date. Keep the Sunday exception aligned with the enable date.

clanky-the-clanker · 2026-10-23T01:32:57Z

This pull request's reviews are posted as pull request reviews: see the review of 3a577d3d.

ask-bonk · 2026-10-23T01:33:07Z

Since last review: 0 resolved, 2 still open, 0 new.

Enables the module registry by compatibility date and removes its startup experimental gate.

Carried forward from the last review: tests (no author changes in their files since then; earlier findings stand)

Not re-run: api-compat, docs, compat-flags, design-simplicity, jsg-gc, kj-style, memory-safety (no author changes in their files since the last review)

_{Reviewed commit: c1ad2c13 · github run}

ask-bonk · 2026-10-23T01:33:10Z

@@ -1569,9 +1569,6 @@ kj::Promise<kj::Own<CompiledWorker>> factory_new_worker(const WorkerFactory& con
  bool usingNewModuleRegistry = isNewModuleRegistryEnabled(featureFlags);
  kj::Maybe<kj::Arc<jsg::modules::ModuleRegistry>> newModuleRegistry;
  if (usingNewModuleRegistry) {


[WARNING] A moduleFallback is still an experimental feature, but this branch now bypasses its only --experimental check. newWorkerdModuleRegistry() receives moduleFallback at lines 1577-1580 and adds an active fallback bundle when it is present (workerd-api.c++:944-983), while the remaining check is inside if (!usingNewModuleRegistry) at lines 1666-1670. Therefore a worker at the new default date can make fallback-service requests without --experimental.

Suggested change

if (usingNewModuleRegistry) {

if (usingNewModuleRegistry) {

KJ_REQUIRE(experimental || moduleFallback == kj::none,

"The module fallback service is an experimental feature. "

"You must run workerd with `--experimental` to use the module fallback service.");

ask-bonk · 2026-10-23T01:33:10Z

      $compatEnableFlag("new_module_registry")
-      $compatDisableFlag("legacy_module_registry");
+      $compatDisableFlag("legacy_module_registry")
+      $compatEnableDate("2026-11-08");


[WARNING] The only accompanying test change exempts this field from weekday validation; it does not depend on the enable-date annotation. Existing date-boundary coverage in compatibility-date-test.c++ covers a different flag (lines 578-588), and the existing new-registry server tests all call allowExperimental() (for example, server-test.c++:1002-1016). Removing this annotation, selecting an incorrect boundary, or restoring the factory-level experimental requirement would therefore pass the test suite. Add coverage for the day before and the day of the default, the legacy_module_registry opt-out, and startup of a default-date module worker without experimental mode.

clanky-the-clanker

Superseded by the review of c1bf288f.

This review, of 3a577d3d

💬 Approved with comments — The change is correct and the opt-out and Python behaviour are kept. What remains is one INFO note about a missing test for the date-driven default and two SUGGESTIONs (a stale comment and the Sunday enable date).

Findings: 1 info · 2 suggestions

_{The decision is advisory: this review is a comment and never approves, blocks or requests changes on the pull request.}

📋 Code Quality: 💬 1 info · 2 suggestions

Unchanged logic is correct; earlier notes on test coverage, a stale comment and the Sunday date remain open.

Recommendation: 💬 Optional Nits

[INFO] No test covers date-to-flag resolution for the new default: before and after 2026-11-08, the legacy_module_registry opt-out, and Python Workers. The existing Python test sets the flag directly. (src/workerd/io/compatibility-date.capnp:517)
[SUGGESTION] The comment "(once the flag has a default-on date)" is stale now that the flag has an enable date. Reword it to describe the current behaviour. (src/workerd/io/compatibility-date-test.c++:770)
[SUGGESTION] The enable date 2026-11-08 is a Sunday and has not shipped, so it needs a weekday exception. Consider a Tuesday to Thursday date, especially if the date moves again as the approver suggested (moving it by whole weeks keeps it on a Sunday). (src/workerd/io/compatibility-date-test.c++:653)

View full review

src/workerd/io/compatibility-date.capnp:517: no test compiles flags from compatibility dates for this flag. A test should check four cases: 2026-11-07 gives false, 2026-11-08 gives true, 2026-11-08 with legacy_module_registry gives false, and 2026-11-08 with python_workers makes isNewModuleRegistryEnabled return false. The existing Python test calls setNewModuleRegistry directly, so it never goes through the date resolution.
src/workerd/io/compatibility-date-test.c++:769-771: the comment still says "(once the flag has a default-on date)". The flag now has an enable date, so the comment should describe the current behaviour.
src/workerd/io/compatibility-date-test.c++:651-653: 2026-11-08 is a Sunday that has not shipped yet, so the change has to add a weekday-test exception. The other entries in that list got their exceptions because their dates had already shipped. A Tuesday to Thursday date would avoid this, unless the announced date is fixed.
Removing the --experimental requirement in worker-factory.c++ is consistent with the new default.

✅ All other checks passed

📝 Documentation: ✅ LGTM

No documentation issues found. The pull request description links a companion docs pull request that documents the new default before its enable date. The stale test comment is covered in the code quality section.

_{Reviewed commit: 3a577d3d}

Compatibility decision: enable the new JavaScript module registry by default for compatibility dates on or after 2026-11-12. Remove the Sunday weekday-check exception because the new date is a Thursday.

clanky-the-clanker

Superseded by the review of d3f01098.

This review, of c1bf288f

💬 Approved with comments — The change is correct and keeps the opt-out and Python behaviour. The only open item is an INFO note that no test covers the date-driven default.

Findings: 1 info

_{The decision is advisory: this review is a comment and never approves, blocks or requests changes on the pull request.}

📋 Code Quality: 💬 1 info

Correct change; one INFO about a missing date-resolution test.

Recommendation: 💬 Optional Nits

[INFO] No test covers date-to-flag resolution for the new default: before and after 2026-11-12, the legacy_module_registry opt-out, and Python Workers. The existing Python test sets the flag directly. (src/workerd/io/compatibility-date.capnp:517)

View full review

No test covers how the compatibility date resolves to the flag. A test should cover four cases:

2026-11-11 gives false.
2026-11-12 gives true.
2026-11-12 with legacy_module_registry gives false.
2026-11-12 with python_workers makes isNewModuleRegistryEnabled return false.

The existing Python test calls setNewModuleRegistry directly, so it never goes through date resolution. This is non-blocking.

_{Reviewed commit: c1bf288f}

…al gate Keep module fallback behind --experimental independently of registry selection. Cover the November 12 compatibility boundary, early opt-in, legacy opt-out, Python exclusion, module-worker startup without experimental mode, and fallback rejection with both registries. Update comments to describe date enablement.

clanky-the-clanker

Superseded by the review of 325d2839.

This review, of d3f01098

✅ Approved — No findings. The new tests cover date resolution for the default, the opt-out, the Python exclusion and the fallback experimental gate, which resolves the earlier coverage note.

_{The decision is advisory: this review is a comment and never approves, blocks or requests changes on the pull request.}

✅ All checks passed

🔒 Security: ✅ LGTM

No security issues found.

📖 AGENTS.md: ✅ LGTM

No AGENTS.md issues found.

📋 Code Quality: ✅ LGTM

src/workerd/io/compatibility-date-test.c++ now builds the flags from a compatibility date and checks isNewModuleRegistryEnabled for 2026-11-11 (off), 2026-11-12 (on), early opt-in with new_module_registry (on), legacy_module_registry (off) and python_workers (off).
worker-factory.c++ checks the module fallback --experimental requirement before the registry branch, so the gate now applies to both registries. Before, it applied only on the legacy path.
The comment edits in features.h describe the current behaviour.

⚡ Performance: ✅ LGTM

No performance issues found.

📝 Documentation: ✅ LGTM

No documentation issues found.

_{Reviewed commit: d3f01098}

clanky-the-clanker

Superseded by the review of 851801c0.

This review, of 325d2839

✅ Approved — No findings. The date-based default, the legacy opt-out, the Python exclusion and the fallback --experimental check are all correct and tested. The new Wasm test pin keeps that test on the registry it was written for.

_{The decision is advisory: this review is a comment and never approves, blocks or requests changes on the pull request.}

✅ All checks passed

🔒 Security: ✅ LGTM

No security issues found.

📖 AGENTS.md: ✅ LGTM

No AGENTS.md issues found.

📋 Code Quality: ✅ LGTM

compatibility-date.capnp sets $compatEnableDate("2026-11-12") on newModuleRegistry, and legacy_module_registry is still the opt-out flag. Python Workers stay on the legacy registry.
worker-factory.c++ checks that module fallback requires --experimental once, before choosing a registry, so the check now covers both registries.
server-test.c++ sets the test compatibility date override and does not enable experimental mode, so it tests starting a Worker without --experimental.
module-fallback-test.mjs covers the date default, explicit opt-in, the legacy opt-out and the legacy default.
wasm-source-url-test.wd-test pins legacy_module_registry on both workers. The @all-compat-flags variant would otherwise run on the new registry.

⚡ Performance: ✅ LGTM

No performance issues found.

📝 Documentation: ✅ LGTM

No documentation issues found. The comment edits in features.h and in the test describe how the code behaves now.

_{Reviewed commit: 325d2839}

Co-authored-by: James M Snell <jsnell@cloudflare.com>

clanky-the-clanker

Superseded by the review of a9c47226.

This review, of 851801c0

💬 Approved with comments — Runtime logic is correct, but 3 WARNINGs remain: the enable date moved to 2026-11-17 while the new tests still use 2026-11-12. As a result the compatibility-date boundary test and the server startup test fail, and the module-fallback gate test no longer covers the date-default path.

Findings: 3 warnings · 1 info (3 are inline comments on the diff)

_{The decision is advisory: this review is a comment and never approves, blocks or requests changes on the pull request.}

🔧 Fix with your agent

Paste the following into your coding agent to investigate and fix these issues.

Fix the following code review issues found in pull request #7799.

Before making changes, review each issue and present a brief summary table:
- For each finding, state whether you agree, disagree, or need clarification
- If you disagree (e.g., the fix would require disproportionate changes
  for minimal ROI, or the finding is factually incorrect), explain why
- If you need to clarify something before deciding, ask those questions
- Then share your plan for which issues to tackle and in what order

## WARNING (3)

### [Code Quality] The boundary test still expects the new registry at 2026-11-12, but the enable date is now 2026-11-17, so `KJ_EXPECT(isNewModuleRegistryEnabled(*enabled))` fails. The opt-out and Python checks at 11-12 now pass whatever they test.
- **File:** src/workerd/io/compatibility-date-test.c++:609

### [Code Quality] The server startup test overrides the date to 2026-11-12, which is now before the enable date. The Worker runs on the legacy registry and does not answer with the expected `date-default:true`.
- **File:** src/workerd/server/server-test.c++:1053

### [Code Quality] The `date-default` and `legacy-opt-out` cases use 2026-11-12, so both run on the legacy registry. The test no longer checks that module fallback is rejected without `--experimental` on the date-default new registry.
- **File:** src/workerd/server/tests/module-fallback/module-fallback-test.mjs:122

## INFO (1)

### [Code Quality] The pull request description says regression coverage checks the "November 12 boundary", and the commit c1bf288f message says 2026-11-12. The enable date is now 2026-11-17, so update both (also the KJ test name at `compatibility-date-test.c++:592`).
- **File:** src/workerd/io/compatibility-date-test.c++:592

📋 Code Quality: ⚠️ 3 warnings · 1 info

The enable date moved to 2026-11-17 but the new tests still use 2026-11-12: two tests fail and the fallback gate test no longer covers what it claims.

Recommendation: 📝 Minor Comments

[WARNING] The boundary test still expects the new registry at 2026-11-12, but the enable date is now 2026-11-17, so KJ_EXPECT(isNewModuleRegistryEnabled(*enabled)) fails. The opt-out and Python checks at 11-12 now pass whatever they test. (src/workerd/io/compatibility-date-test.c++:609)
[WARNING] The server startup test overrides the date to 2026-11-12, which is now before the enable date. The Worker runs on the legacy registry and does not answer with the expected date-default:true. (src/workerd/server/server-test.c++:1053)
[WARNING] The date-default and legacy-opt-out cases use 2026-11-12, so both run on the legacy registry. The test no longer checks that module fallback is rejected without --experimental on the date-default new registry. (src/workerd/server/tests/module-fallback/module-fallback-test.mjs:122)
[INFO] The pull request description says regression coverage checks the "November 12 boundary", and the commit c1bf288 message says 2026-11-12. The enable date is now 2026-11-17, so update both (also the KJ test name at compatibility-date-test.c++:592). (src/workerd/io/compatibility-date-test.c++:592)

View full review

src/workerd/io/compatibility-date.capnp:517 now sets $compatEnableDate("2026-11-17"). Every date in the new tests is still 2026-11-12 or 2026-11-11.

compatibility-date-test.c++:607-615
- compileFlags("2026-11-12", {}) now returns a disabled registry, so KJ_EXPECT(isNewModuleRegistryEnabled(*enabled)) fails.
- The opt-out and Python assertions at 11-12 pass whatever they test, and the "before" case no longer checks the boundary.
server-test.c++:1053
- The date override of 2026-11-12 selects the legacy registry, so the Worker does not answer with the expected date-default:true.
module-fallback-test.mjs:122-125
- date-default now runs on the legacy registry.
- legacy-opt-out no longer exercises an opt-out.
- Both still pass, but only because the --experimental check covers both registries, so the new-registry path is no longer covered by the date default.
Pull request description: it says "Regression coverage checks the November 12 boundary", while its first paragraph says 2026-11-17.

Fix: use 2026-11-16 for the "before" cases and 2026-11-17 for the "on" cases, and rename the KJ test.

✅ All other checks passed

🔒 Security: ✅ LGTM

No security issues found. The --experimental check for module fallback runs before the registry is chosen, so it covers both registries.

📖 AGENTS.md: ✅ LGTM

No AGENTS.md issues found.

⚡ Performance: ✅ LGTM

No performance issues found.

📝 Documentation: ✅ LGTM

No documentation issues found in the changed comments.

_{Reviewed commit: 851801c0}

clanky-the-clanker · 2026-10-31T00:19:16Z

+  auto before = compileFlags("2026-11-11", {});
+  KJ_EXPECT(!isNewModuleRegistryEnabled(*before));
+  auto enabled = compileFlags("2026-11-12", {});
+  KJ_EXPECT(isNewModuleRegistryEnabled(*enabled));
+  auto optedIn = compileFlags("2026-11-11", {"new_module_registry"_kj});
+  KJ_EXPECT(isNewModuleRegistryEnabled(*optedIn));
+  auto optedOut = compileFlags("2026-11-12", {"legacy_module_registry"_kj});
+  KJ_EXPECT(!isNewModuleRegistryEnabled(*optedOut));
+  auto python = compileFlags("2026-11-12", {"python_workers"_kj});


⚠️ WARNING · Code Quality

The boundary test still expects the new registry at 2026-11-12, but the enable date is now 2026-11-17, so KJ_EXPECT(isNewModuleRegistryEnabled(*enabled)) fails. The opt-out and Python checks at 11-12 now pass whatever they test.

compatibility-date.capnp:517 now enables newModuleRegistry from 2026-11-17, so compileFlags("2026-11-12", {}) returns the legacy registry and this KJ_EXPECT fails. The optedOut and python checks at 11-12 also pass without testing anything, and before at 11-11 no longer checks the boundary. Move the dates to 2026-11-16 and 2026-11-17, and rename the test on line 592.

Suggested change

auto before = compileFlags("2026-11-11", {});

KJ_EXPECT(!isNewModuleRegistryEnabled(*before));

auto enabled = compileFlags("2026-11-12", {});

KJ_EXPECT(isNewModuleRegistryEnabled(*enabled));

auto optedIn = compileFlags("2026-11-11", {"new_module_registry"_kj});

KJ_EXPECT(isNewModuleRegistryEnabled(*optedIn));

auto optedOut = compileFlags("2026-11-12", {"legacy_module_registry"_kj});

KJ_EXPECT(!isNewModuleRegistryEnabled(*optedOut));

auto python = compileFlags("2026-11-12", {"python_workers"_kj});

auto before = compileFlags("2026-11-16", {});

KJ_EXPECT(!isNewModuleRegistryEnabled(*before));

auto enabled = compileFlags("2026-11-17", {});

KJ_EXPECT(isNewModuleRegistryEnabled(*enabled));

auto optedIn = compileFlags("2026-11-16", {"new_module_registry"_kj});

KJ_EXPECT(isNewModuleRegistryEnabled(*optedIn));

auto optedOut = compileFlags("2026-11-17", {"legacy_module_registry"_kj});

KJ_EXPECT(!isNewModuleRegistryEnabled(*optedOut));

auto python = compileFlags("2026-11-17", {"python_workers"_kj});

clanky-the-clanker · 2026-10-31T00:19:16Z

+    ]
+  ))"_kj));
+
+  test.server.setTestCompatibilityDateOverride(kj::str("2026-11-12"));


⚠️ WARNING · Code Quality

The server startup test overrides the date to 2026-11-12, which is now before the enable date. The Worker runs on the legacy registry and does not answer with the expected date-default:true.

With the enable date at 2026-11-17, this override selects the legacy registry. The test then no longer checks that the default registry starts without --experimental, and the import.meta.main response will not be date-default:true. Override to 2026-11-17 instead.

Suggested change

test.server.setTestCompatibilityDateOverride(kj::str("2026-11-12"));

test.server.setTestCompatibilityDateOverride(kj::str("2026-11-17"));

clanky-the-clanker · 2026-10-31T00:19:16Z

+    ['date-default', '2026-11-12', []],
+    ['explicit-opt-in', '2026-11-11', ['new_module_registry']],
+    ['legacy-opt-out', '2026-11-12', ['legacy_module_registry']],
+    ['legacy-default', '2026-11-11', []],


⚠️ WARNING · Code Quality

The date-default and legacy-opt-out cases use 2026-11-12, so both run on the legacy registry. The test no longer checks that module fallback is rejected without --experimental on the date-default new registry.

With the enable date at 2026-11-17, date-default at 2026-11-12 runs on the legacy registry, and legacy-opt-out no longer exercises an opt-out. Both still pass, so a regression in the fallback check on the date-default registry would go unnoticed. Use 2026-11-17 for the "on" cases and 2026-11-16 for the "before" cases.

Suggested change

['date-default', '2026-11-12', []],

['explicit-opt-in', '2026-11-11', ['new_module_registry']],

['legacy-opt-out', '2026-11-12', ['legacy_module_registry']],

['legacy-default', '2026-11-11', []],

['date-default', '2026-11-17', []],

['explicit-opt-in', '2026-11-16', ['new_module_registry']],

['legacy-opt-out', '2026-11-17', ['legacy_module_registry']],

['legacy-default', '2026-11-16', []],

clanky-the-clanker

✅ Approved — All four findings from the previous review are fixed: the tests now use the 2026-11-16 and 2026-11-17 dates around the enable date. No new issues were found in the runtime change or the tests.

_{The decision is advisory: this review is a comment and never approves, blocks or requests changes on the pull request.}

✅ All checks passed

🔒 Security: ✅ LGTM

The --experimental check for the module fallback service runs before the registry is chosen. Its condition is experimental || moduleFallback == kj::none, so it covers both registries. Removing the new-registry gate does not widen access to the experimental fallback service.

📖 AGENTS.md: ✅ LGTM

No AGENTS.md issues found.

📋 Code Quality: ✅ LGTM

The earlier findings are fixed:

compatibility-date-test.c++:592-616 is renamed to "defaults on at 2026-11-17". It uses 2026-11-16 for the before and early opt-in cases, and 2026-11-17 for the enabled, opt-out and Python cases.
server-test.c++:1053 overrides the date to 2026-11-17, so the new registry is selected.
module-fallback-test.mjs:122-125 runs date-default and legacy-opt-out at 2026-11-17, and explicit-opt-in and legacy-default at 2026-11-16, so both registries are covered again.

In worker-factory.c++, the --experimental requirement for module fallback now runs before the registry is chosen, so it applies to both registries.

⚡ Performance: ✅ LGTM

No performance issues found.

📝 Documentation: ✅ LGTM

No issues found in the changed comments.

_{Reviewed commit: a9c47226}

irvinebroque force-pushed the codex/module-registry-default-nov-2026 branch from 44e588e to 468f632 Compare October 17, 2026 15:25

irvinebroque mentioned this pull request Oct 17, 2026

[Workers] Announce module registry default on November 17 cloudflare/cloudflare-docs#34425

Open

2 tasks done

irvinebroque force-pushed the codex/module-registry-default-nov-2026 branch 2 times, most recently from 4442cca to f51bc6c Compare October 17, 2026 15:41

irvinebroque force-pushed the codex/module-registry-default-nov-2026 branch from f51bc6c to 9113db3 Compare October 17, 2026 15:58

irvinebroque requested a review from jasnell October 17, 2026 17:07

jasnell approved these changes Oct 20, 2026

View reviewed changes

Delay new module registry default to 2026-11-08

e7b1cc8

Compatibility decision: use the new JavaScript module registry for compatibility dates on or after 2026-11-08, one week after the previously scheduled date. Keep the Sunday exception aligned with the enable date.

irvinebroque changed the title ~~Enable the new module registry by default from 2026-11-01~~ Enable the new module registry by default from 2026-11-08 Oct 23, 2026

irvinebroque marked this pull request as ready for review October 23, 2026 01:29

irvinebroque requested review from a team as code owners October 23, 2026 01:29

Merge branch 'main' into codex/module-registry-default-nov-2026

c1ad2c1

ask-bonk Bot reviewed Oct 23, 2026

View reviewed changes

Merge branch 'main' into codex/module-registry-default-nov-2026

3a577d3

irvinebroque enabled auto-merge October 30, 2026 03:11

clanky-the-clanker Bot reviewed Oct 30, 2026

View reviewed changes

Delay new module registry default to 2026-11-12

c1bf288

Compatibility decision: enable the new JavaScript module registry by default for compatibility dates on or after 2026-11-12. Remove the Sunday weekday-check exception because the new date is a Thursday.

irvinebroque changed the title ~~Enable the new module registry by default from 2026-11-08~~ Enable the new module registry by default from 2026-11-12 Oct 30, 2026

clanky-the-clanker Bot reviewed Oct 30, 2026

View reviewed changes

Keep legacy Wasm source URL cases on the legacy module registry

325d283

clanky-the-clanker Bot reviewed Oct 30, 2026

View reviewed changes

jasnell reviewed Oct 31, 2026

View reviewed changes

Comment thread src/workerd/io/compatibility-date.capnp Resolved

irvinebroque and others added 2 commits October 30, 2026 17:16

Update src/workerd/io/compatibility-date.capnp

4cf9716

Co-authored-by: James M Snell <jsnell@cloudflare.com>

Merge branch 'main' into codex/module-registry-default-nov-2026

851801c

clanky-the-clanker Bot reviewed Oct 31, 2026

View reviewed changes

irvinebroque changed the title ~~Enable the new module registry by default from 2026-11-12~~ Enable the new module registry by default from 2026-11-17 Oct 31, 2026

Align module registry default tests with November 17

a9c4722

clanky-the-clanker Bot reviewed Oct 31, 2026

View reviewed changes

-  if (usingNewModuleRegistry) {
+  if (usingNewModuleRegistry) {
+    KJ_REQUIRE(experimental || moduleFallback == kj::none,
+        "The module fallback service is an experimental feature. "
+        "You must run workerd with `--experimental` to use the module fallback service.");

	test.server.setTestCompatibilityDateOverride(kj::str("2026-11-12"));
	test.server.setTestCompatibilityDateOverride(kj::str("2026-11-17"));

Conversation

irvinebroque commented Oct 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jasnell left a comment

Choose a reason for hiding this comment

Uh oh!

clanky-the-clanker Bot commented Oct 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ask-bonk Bot commented Oct 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ask-bonk Bot Oct 23, 2026

Choose a reason for hiding this comment

Uh oh!

ask-bonk Bot Oct 23, 2026

Choose a reason for hiding this comment

Uh oh!

clanky-the-clanker Bot left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

📋 Code Quality: 💬 1 info · 2 suggestions

📝 Documentation: ✅ LGTM

Uh oh!

clanky-the-clanker Bot left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

📋 Code Quality: 💬 1 info

Uh oh!

clanky-the-clanker Bot left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

🔒 Security: ✅ LGTM

📖 AGENTS.md: ✅ LGTM

📋 Code Quality: ✅ LGTM

⚡ Performance: ✅ LGTM

📝 Documentation: ✅ LGTM

Uh oh!

clanky-the-clanker Bot left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

🔒 Security: ✅ LGTM

📖 AGENTS.md: ✅ LGTM

📋 Code Quality: ✅ LGTM

⚡ Performance: ✅ LGTM

📝 Documentation: ✅ LGTM

Uh oh!

Uh oh!

clanky-the-clanker Bot left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

📋 Code Quality: ⚠️ 3 warnings · 1 info

🔒 Security: ✅ LGTM

📖 AGENTS.md: ✅ LGTM

⚡ Performance: ✅ LGTM

📝 Documentation: ✅ LGTM

Uh oh!

clanky-the-clanker Bot Oct 31, 2026

Choose a reason for hiding this comment

Uh oh!

clanky-the-clanker Bot Oct 31, 2026

Choose a reason for hiding this comment

Uh oh!

clanky-the-clanker Bot Oct 31, 2026

Choose a reason for hiding this comment

Uh oh!

clanky-the-clanker Bot left a comment

Choose a reason for hiding this comment

🔒 Security: ✅ LGTM

📖 AGENTS.md: ✅ LGTM

📋 Code Quality: ✅ LGTM

⚡ Performance: ✅ LGTM

📝 Documentation: ✅ LGTM

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

irvinebroque commented Oct 17, 2026 •

edited

Loading

clanky-the-clanker Bot commented Oct 23, 2026 •

edited

Loading

ask-bonk Bot commented Oct 23, 2026 •

edited

Loading

clanky-the-clanker Bot left a comment •

edited

Loading

clanky-the-clanker Bot left a comment •

edited

Loading

clanky-the-clanker Bot left a comment •

edited

Loading

clanky-the-clanker Bot left a comment •

edited

Loading

clanky-the-clanker Bot left a comment •

edited

Loading