Service eligibility and regional restrictions
PuppyIP serves only compliant overseas businesses and their authorized personnel. Proxy services are not available in mainland China. The service may only be used for lawful business activities outside mainland China. Use of this service within mainland China is prohibited.
Hosting a proxy IP or server overseas does not change these restrictions. The service must not be provided to end users in mainland China through relaying, forwarding, sharing or resale. Before use, read the Terms of Service.
Key Takeaways
- Starting November 17, 2026, JavaScript Workers dated 2026-11-17 or later default to the new module registry; this is not a simultaneous switch for every Worker.
- Python Workers stay on the legacy registry. Existing Workers keep their current behavior until their compatibility date or flags change.
- To try the registry before the date threshold, add new_module_registry to the existing compatibility configuration. To keep the legacy registry at or beyond the threshold, use legacy_module_registry and retain other flags.
- The new registry improves JavaScript standards and Node.js compatibility. With Node.js compatibility enabled, require() can load ES modules only when neither the target module nor any dependency uses top-level await.
- import.meta.url, main and resolve() expose module details or a URL within the bundle. resolve() does not check that a module exists or load it from the network, and build tools may transform import.meta.
November 17 changes the default, not every Worker at once
In its November 2, 2026 announcement, Cloudflare said that JavaScript Workers with a compatibility date of 2026-11-17 or later will use the new module registry by default starting November 17. The registry locates and loads JavaScript modules inside a Worker; this change is intended to improve compatibility with JavaScript standards and Node.js behavior.
Python Workers continue using the legacy registry. The announcement also says existing Workers keep their current behavior until their compatibility date or flags change. The calendar date alone therefore does not mean that the platform rewrites every deployed script into the same configuration.
Choose deliberately between trying the new registry and keeping the old one
To try the new registry before the date threshold, add new_module_registry to the existing configuration while keeping the current compatibility date. At or beyond the threshold, add legacy_module_registry if the Worker needs the legacy registry. Treat these flags as deliberate behavior choices rather than a reason to make a blanket change after the announcement.
When changing a Wrangler configuration, merge the flag into the existing compatibility_flags list and keep the project’s other flags. Avoid replacing the full configuration with a one-flag example. Use the project’s existing configuration process and verify the date and flags in the final deployment.
Review require() and the full dependency graph
The new registry improves compatibility with JavaScript standards and Node.js. With Node.js compatibility enabled, require() can load an ES module only if neither the target module nor any of its dependencies uses top-level await; checking the entry file alone is not enough.
The new registry rejects invalid import attributes. Before switching, inspect the bundled dependency graph, module attributes and require() calls. Include transitive dependencies: the other modules that the target module imports, including those that may use top-level await.
import.meta exposes module details and bundle URLs
The new registry supports import.meta.url for the current module's URL, import.meta.main to tell whether the current module is the entry point, and import.meta.resolve() to return the URL of another module in the Worker bundle. In Cloudflare's example, isEntrypoint is true when src/index.ts is deployed as an unbundled entry point.
A URL from resolve() does not confirm that the target module exists, and it does not load the module over the network. Cloudflare also notes that build tools may transform import.meta. If you bundle the Worker, inspect the emitted output and deployment artifact rather than assuming the unbundled example describes the production bundle.
What to check before changing the configuration
Before making a change, record each environment's compatibility date, flags, runtime options and bundler version. Review the complete module graph, import attributes, require() paths and import.meta usage. In an isolated Worker, run representative imports with the intended date and flags, then inspect the built entry point and bundle URLs.
This is a migration-preparation checklist, not a report of runtime acceptance in a real Cloudflare account. Saving a configuration snippet, building one entry point or receiving a URL from resolve() does not prove that the complete production dependency set works. Validate the module graph and build artifact for the target environment before deciding to change its compatibility date.
Sources
Frequently Asked Questions
At what time and in which time zone will Cloudflare apply the November 17 change?
The announcement gives the date and compatibility-date threshold, but no exact time, time zone or per-account activation window. Do not infer a local-midnight cutover; check later Cloudflare updates or the configuration state of the specific project when scheduling a precise change window.
Will Cloudflare automatically scan dependencies and create a migration report for each project?
The announcement does not promise automatic dependency scanning or a per-project migration report, so do not assume the platform will identify every issue in transitive dependencies in advance. Maintainers should inspect their own bundles and runtime paths; whether a particular tool offers additional reporting depends on its current product documentation.