-
Notifications
You must be signed in to change notification settings - Fork 690
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
BLOCKED fix: remove experimental:
prefix requirement for nodejs_compat_v2
#6545
Conversation
🦋 Changeset detectedLatest commit: 8cb9690 The changes in this PR will be included in the next version bump. This PR includes changesets to release 2 packages
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 |
A wrangler prerelease is available for testing. You can install this latest build in your project with: npm install --save-dev https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/10508136058/npm-package-wrangler-6545 You can reference the automatically updated head of this PR with: npm install --save-dev https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/prs/6545/npm-package-wrangler-6545 Or you can use npx https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/10508136058/npm-package-wrangler-6545 dev path/to/script.js Additional artifacts:npx https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/10508136058/npm-package-create-cloudflare-6545 --no-auto-update npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/10508136058/npm-package-cloudflare-kv-asset-handler-6545 npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/10508136058/npm-package-miniflare-6545 npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/10508136058/npm-package-cloudflare-pages-shared-6545 npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/10508136058/npm-package-cloudflare-vitest-pool-workers-6545 npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/10508136058/npm-package-cloudflare-workers-editor-shared-6545 npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/10508136058/npm-package-cloudflare-workers-shared-6545 Note that these links will no longer work once the GitHub Actions artifact expires.
Please ensure constraints are pinned, and |
* Currently we require that the v2 mode is configured via `experimental:nodejs_compat_v2` compat flag, | ||
* where the `experimental:` prefix is stripped before being passed to the runtime since that does not | ||
* understand this prefix. | ||
* Currently we require that the v2 mode is configured via `nodejs_compat_v2` compat flag. |
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.
"Currently" -> "As of September 2024" ?
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.
It is actually whenever we land this and release Wrangler.
So I'd rather not put a date in here.
const nodejsCompatV2 = compatibility_flags.includes( | ||
"experimental:nodejs_compat_v2" | ||
); | ||
const nodejsCompatV2 = compatibility_flags.includes("nodejs_compat_v2"); |
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.
nodejsCompatV2 === true
implies nodejsCompat === true
because of the common prefix - this is probably a bug?
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.
A few more nits - not directly related to this PR.
- What about renaming
node_compat
tonodeCompatLegacy
? - Could setting legacy use
mode
instead ofnode_compat
? - Any reason we are not using enums for flag names and mode?
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.
nodejsCompatV2 === true
impliesnodejsCompat === true
because of the common prefix - this is probably a bug?
compatibility_flags
is an array of strings, so these include()
calls are correct.
E.g.
["nodejs_compat_v2"].includes("nodejs_compat") === false
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.
What about renaming node_compat to nodeCompatLegacy?
It is called node_compat
in the config object, which is passed here.
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.
Any reason we are not using enums for flag names and mode?
We don't tend to use enums much in this code base. It is nice to have strings when debugging.
Any reason to use enums?
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.
Could setting legacy use mode instead of node_compat?
Not sure what you mean here?
To be clear, what this function does is compute the mode
, but also return flags telling us if any of these properties were turned on, so we can check the validaty of combinations.
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.
Any reason to use enums?
Avoid repeating a string with the risk of a typo.
enum
- can be strings
enum Mode { V1 = "v1", Legacy="legacy"}
- support autocomplete
- support exhaustive switch (i.e. warn/error when adding a value and not updating a switch)
- are easier to search in the code (arguably)
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.
Not sure what you mean here?
legacy: node_compat === true,
-> legacy: mode === "legacy",
Just to avoid repeating logic as repeating might lead to out of sync code
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.
Any reason to use enums?
Avoid repeating a string with the risk of a typo. enum
- can be strings
enum Mode { V1 = "v1", Legacy="legacy"}
- support autocomplete
- support exhaustive switch (i.e. warn/error when adding a value and not updating a switch)
- are easier to search in the code (arguably)
Since the type is a narrow collection of const strings we get all those already: https://www.typescriptlang.org/play/?#code/KYDwDg9gTgLgBDAnmYcByEAmwBSBlAYQgFswBDGAWS1QF44AiAG2AHMyBjRBuAH0YBuARh78GAgEyi4AOwCuTJgG4AUCo4QZAZ3hkAXOhr4ipCtWxx6zNp26qN2+ACMDGbMZLkqNS4JH3NHTgOVyNCTzMfK0kGAMc4TFD3cNNvC3p5RTigpzJEw2STL3M6RgAzCAgGNWwOJjIoVDK5GQ4YAEtNOFZgNOAACgBKJNwU4ppVFS0Ad3aYDgALOH6evqHBuABvFThd4LItVGt2LgY9Hb3Lp0ayAGtVS44Do+Ezi8vd6+A7h72nw8EUnOHz2Xx+732AIYuUwbxBnxu9wh-1QmSYwPhYKRAF8gA
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.
Not sure what you mean here?
legacy: node_compat === true,
->legacy: mode === "legacy",
Just to avoid repeating logic as repeating might lead to out of sync code
Ah I see! I can create an extra var to DRY that.
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.
lgtm!
one more thing to consider: do we want to issue a nice warning to users that are currently using the experimental prefix? could we error and tell them that the flag is no longer experimental and they should update their config rather than error with message saying that the flag doesn't exist, which I think will happen once this change is merged.
@@ -94,39 +78,25 @@ export function getNodeCompatMode({ | |||
compatibility_flags, | |||
node_compat, | |||
}: Pick<Config, "compatibility_flags" | "node_compat">) { | |||
const legacy = node_compat === true; |
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.
isn't v1 also considered a legacy mode?
what will this code look like when v2 is the default and v1 is legacy (which should happen soon). consider tweaking this name a bit to make it more future proof.
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.
Legacy is a special pre-nodejs_compat
mode.
After we got nodejs_compat
we go into versioned mode, e.g. v1, v2, etc.
V1 is not legacy it is just an older version of the same mode.
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.
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.
We will support it forever, but it will become flagged on the combination of compatibilty flag (nodejs_compat
) and the compatibility date (e.g. older than X September 2024).
569679a
to
7b8d4ea
Compare
Very good point. I'll add that. |
7b8d4ea
to
8cb9690
Compare
mode = "legacy"; | ||
} else { | ||
mode = null; | ||
} | ||
|
||
return { | ||
legacy: node_compat === true, | ||
legacy, |
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.
I would love this function to return a single value for clarity.
It looks to me that legacy
, nodejsCompat
, and nodejsCompatv2
can be collapsed into mode.
experimentalNodejsCompatV2
might be handled in a different functions.
Closing in favour of #6593 |
See https://jira.cfdata.org/browse/DEVDASH-218
What this PR solves / how to test
Fixes #[insert GH or internal issue number(s)].
Author has addressed the following