[irvinebroque]

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-08. 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.

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

[jasnell]

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

[clanky-the-clanker]

💬 Approved with comments — The change is small and correct. Python Workers stay on the legacy registry and the --experimental removal is safe. One WARNING asks for a test of the new 2026-11-08 default, and two SUGGESTIONs cover comment wording and the choice of a Sunday date.

Findings: 1 warning · 2 suggestions

_{The decision is advisory: this comment 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 (1)

### [Code Quality] No test checks the new default: off before 2026-11-08, on from that date, still off with `legacy_module_registry`, and never used for Python Workers. A wrong date or a broken opt-out would change which registry production Workers load with, and no test would fail.
- **File:** src/workerd/io/compatibility-date.capnp:517

## SUGGESTION (2)

### [Code Quality] The comment "(once the flag has a default-on date)" is out of date now that the flag has an enable date. Reword it to describe the current behavior.
- **File:** src/workerd/io/compatibility-date-test.c++:770

### [Code Quality] The enable date is a Sunday and has not shipped yet, so it needs a weekday-test exception that the other entries got only because their dates had already shipped. Consider a Tuesday to Thursday date unless the announced date is fixed.
- **File:** src/workerd/io/compatibility-date-test.c++:653

---

📋 Code Quality: ⚠️ 1 warning · 2 suggestions

The change is correct, but no test checks the date-driven default. There are also two comment and date-choice nits.

Recommendation: 📝 Minor Comments

• [WARNING] No test checks the new default: off before 2026-11-08, on from that date, still off with legacy_module_registry, and never used for Python Workers. A wrong date or a broken opt-out would change which registry production Workers load with, and no test would fail. (src/workerd/io/compatibility-date.capnp:517)
• [SUGGESTION] The comment "(once the flag has a default-on date)" is out of date now that the flag has an enable date. Reword it to describe the current behavior. (src/workerd/io/compatibility-date-test.c++:770)
• [SUGGESTION] The enable date is a Sunday and has not shipped yet, so it needs a weekday-test exception that the other entries got only because their dates had already shipped. Consider a Tuesday to Thursday date unless the announced date is fixed. (src/workerd/io/compatibility-date-test.c++:653)

View full review

Missing test for the date-driven default (src/workerd/io/compatibility-date.capnp:514-517, src/workerd/io/compatibility-date-test.c++)

This pull request turns on the new registry for every JavaScript Worker with a compatibility date on or after 2026-11-08. No test checks that date. The existing test isNewModuleRegistryEnabled ignores the flag for Python workers (compatibility-date-test.c++:758) sets the flag directly with setNewModuleRegistry, so it never goes through date-to-flag resolution. Please add a test that compiles flags from dates and checks:

• 2026-11-07 gives false
• 2026-11-08 gives true
• 2026-11-08 with legacy_module_registry gives false
• 2026-11-08 with python_workers makes isNewModuleRegistryEnabled return false

Stale comment (compatibility-date-test.c++:769-771)

The comment still says "(once the flag has a default-on date)". The flag now has one, so the comment should describe the current behavior.

Sunday enable date (compatibility-date-test.c++:593, 651-653)

2026-11-08 is a Sunday, so the pull request adds newModuleRegistry to the weekday-exception list. The other entries are dates that had already shipped. This one has not shipped yet, and the old "already deployed and can't be changed" justification was deleted from the list's comment. If an external announcement fixes the date, that is fine. Otherwise a Tuesday to Thursday date such as 2026-11-10 would avoid the exception, though the companion docs would need the same change.

Checked, no issue

• Removing KJ_REQUIRE(experimental, ...) in worker-factory.c++ is safe. The flag is not $experimental, nothing else requires --experimental for the new registry, and experimental is still used elsewhere in the function.
• Python Workers stay on the legacy registry because isNewModuleRegistryEnabled (io/features.h) excludes them.
• The @all-compat-flags test variants (compatibility date 2999-12-31) will now run under the new registry unless a test sets legacy_module_registry. This review did not run those tests to confirm they pass.

---

✅ All other checks passed

📝 Documentation: ✅ LGTM

No documentation issues found. The pull request description links a companion docs pull request that documents the flag before its enable date.

---

_{Reviewed commit: c1ad2c13}

[ask-bonk]

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]

[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]

[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.