Skip to content

Enable the new module registry by default from 2026-11-08 #7799

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
irvinebroque wants to merge 3 commits into
base: main
Choose a base branch
from
Open

Enable the new module registry by default from 2026-11-08 #7799

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
9113db3
Enable the new module registry by default from 2026-11-01
irvinebroque Oct 17, 2026
e7b1cc8
Delay new module registry default to 2026-11-08
irvinebroque Oct 23, 2026
c1ad2c1
Merge branch 'main' into codex/module-registry-default-nov-2026
irvinebroque Oct 23, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 4 additions & 2 deletions src/workerd/io/compatibility-date-test.c++
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -590,8 +590,7 @@ KJ_TEST("encode to full flag list") {
}

KJ_TEST("compatibility dates must be Tuesday, Wednesday, or Thursday") {
// List of specific flags that are allowed to use non-conformant dates
// (already deployed and can't be changed for compatibility reasons)
// Specific flags with compatibility dates outside the normal release weekdays.
kj::HashSet<kj::StringPtr> allowedFlagExceptions;
allowedFlagExceptions.insertAll(std::initializer_list<kj::StringPtr>{
// Existing non-conformant dates that are already deployed
Expand Down Expand Up @@ -649,6 +648,9 @@ KJ_TEST("compatibility dates must be Tuesday, Wednesday, or Thursday") {
"pythonWorkers20250116"_kj, // 2025-09-29 (Monday) via impliedByAfterDate
"removeNodejsCompatEOLv22"_kj, // 2027-04-30 (Friday) via impliedByAfterDate
"removeNodejsCompatEOLv24"_kj, // 2028-04-30 (Sunday) via impliedByAfterDate

// Scheduled default enablement on November 8, 2026 (Sunday).
"newModuleRegistry"_kj,
});

// Helper function to suggest the next valid date (Tuesday, Wednesday, or Thursday)
Expand Down
3 changes: 2 additions & 1 deletion src/workerd/io/compatibility-date.capnp
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,3 +1,3 @@
# Copyright (c) 2017-2022 Cloudflare, Inc.
# Licensed under the Apache 2.0 license found in the LICENSE file or at:
# https://opensource.org/licenses/Apache-2.0
Expand Down Expand Up @@ -513,7 +513,8 @@

newModuleRegistry @52 :Bool
$compatEnableFlag("new_module_registry")
$compatDisableFlag("legacy_module_registry");
$compatDisableFlag("legacy_module_registry")
$compatEnableDate("2026-11-08");

@ask-bonk ask-bonk Bot Oct 23, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

# Enables the new module registry implementation, which handles module
# specifiers as URLs, implements import.meta (url/main/resolve), supports
# import attributes, and allows a registry to be shared across isolate
Expand Down
3 changes: 0 additions & 3 deletions src/workerd/server/factory/worker-factory.c++
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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) {

@ask-bonk ask-bonk Bot Oct 23, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[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.");

KJ_REQUIRE(experimental,
"The new ModuleRegistry implementation is an experimental feature. "
"You must run workerd with `--experimental` to use this feature.");
// Module URLs follow the virtual file system: a module at "/foo/bar/baz.js" in the bundle
// is "file:///foo/bar/baz.js".
const jsg::Url& bundleBase = workerFs->getBundleRoot();
Expand Down
Loading