-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Use the native workerd perf_hooks modules when available #10618
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.
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
base: main
Are you sure you want to change the base?
Conversation
🦋 Changeset detectedLatest commit: 80639b6 The changes in this PR will be included in the next version bump. Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
create-cloudflare
@cloudflare/kv-asset-handler
miniflare
@cloudflare/pages-shared
@cloudflare/unenv-preset
@cloudflare/vite-plugin
@cloudflare/vitest-pool-workers
@cloudflare/workers-editor-shared
@cloudflare/workers-utils
wrangler
commit: |
|
Wrangler e2e failures are because the |
|
Could you please address the points I commented on your other PR |
vicb
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Need to sync on cloudflare/workerd#5099 before merging this
Previously, the unenv-preset always used a polyfill for perf_hooks, which was provided in the unenv libray. This polyfill used sniffing of the `performance.addEventListener` method to determine if the environment supported the perf_hooks API natively, and if so, it would use the native implementation. However, now that the native `performance` object has been updated to provide stubs for many of these methods, the sniffing approach no longer works. This change moves the perf_hooks polyfill into the unenv-preset package, and removes the sniffing logic. The decision whether to use the native or polyfill implementation is now made based on whether the `enable_nodejs_perf_hooks_module` flag is set.
d261cd5 to
80639b6
Compare
Previously, the unenv-preset always used a polyfill for perf_hooks, which was provided in the unenv libray. This polyfill used sniffing of the
performance.addEventListenermethod to determine if the environment supported the perf_hooks API natively, and if so, it would use the native implementation.However, now that the native
performanceobject has been updated to provide stubs for many of these methods, the sniffing approach no longer works.This change moves the perf_hooks polyfill into the unenv-preset package, and removes the sniffing logic. The decision whether to use the native or polyfill implementation is now made based on whether the
enable_nodejs_perf_hooks_moduleflag is set.There are two compat flags of note:
enable_global_performance_classes("class") - only enables some standard performance classes and can be used without nodejs_compat.enable_nodejs_perf_hooks_module("module") - enables node:perf_hooks but is also a superset of the "class" flag. It enables the standard global classes along with some non-standard node specific classes.After the compat date (21 Sept) the "class" flag will be enabled by default and the "module" flag will be implied by nodejs_compat.
I think that we only need to care about the "module" flag, since if
nodejs_compatis not enabled then we just don't do polyfilling at all for this.The only weird scenario that may be problematic is if the "module" one is enabled while the "class" one is disabled. But this is not a problem because the global classes are enabled if "either" of the flags is enabled.