-
Notifications
You must be signed in to change notification settings - Fork 726
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
feat: add runtime type generation to wrangler types command #6295
Conversation
🦋 Changeset detectedLatest commit: a2eed89 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/10055066450/npm-package-wrangler-6295 You can reference the automatically updated head of this PR with: npm install --save-dev https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/prs/6295/npm-package-wrangler-6295 Or you can use npx https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/10055066450/npm-package-wrangler-6295 dev path/to/script.js Additional artifacts:npx https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/10055066450/npm-package-create-cloudflare-6295 --no-auto-update npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/10055066450/npm-package-cloudflare-kv-asset-handler-6295 npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/10055066450/npm-package-miniflare-6295 npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/10055066450/npm-package-cloudflare-pages-shared-6295 npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/10055066450/npm-package-cloudflare-vitest-pool-workers-6295 Note that these links will no longer work once the GitHub Actions artifact expires.
Please ensure constraints are pinned, and |
const updatedTypesString = buildUpdatedTypesString(existingTypes, outFile); | ||
|
||
const message = isWorkersTypesInstalled | ||
? `\n📣 Replace the existing "@cloudflare/workers-types" entry with the generated types path:` |
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'm not sure what is the convention for using emojis here. Without them it's a little dull and harder to read, but maybe we have another way to do this?
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.
Emojis are fun, so this seems fine to me? 🤷
@@ -468,6 +487,7 @@ function writeDTSFile({ | |||
combinedTypeStrings, | |||
].join("\n") | |||
); | |||
logger.log(`Generating project types...\n`); |
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 referred to this as "project types", but open to suggestions of course.
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.
Should it match the --x-with-runtime arg and say "Generating runtime types..."
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.
This is not for the runtime types, but for the Env
types, so the wording is for distinguishing between the two.
chore: remove unused file chore: add changeset chore: remove unnecessary fixture chore: add try/catch to JSON.parse chore: update changeset chore: update changeset and isolate tests chore: revert pnpm lock changes
1eb2fe4
to
b8f90c1
Compare
const updatedTypesString = buildUpdatedTypesString(existingTypes, outFile); | ||
|
||
const message = isWorkersTypesInstalled | ||
? `\n📣 Replace the existing "@cloudflare/workers-types" entry with the generated types path:` |
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.
Emojis are fun, so this seems fine to me? 🤷
packages/wrangler/src/type-generation/runtime/log-runtime-types-message.ts
Outdated
Show resolved
Hide resolved
packages/wrangler/src/type-generation/runtime/log-runtime-types-message.ts
Outdated
Show resolved
Hide resolved
packages/wrangler/src/type-generation/runtime/log-runtime-types-message.ts
Outdated
Show resolved
Hide resolved
packages/wrangler/src/type-generation/runtime/log-runtime-types-message.ts
Outdated
Show resolved
Hide resolved
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.
Looks good to me! One additional thing that would be good to see is some sort of comment header at the top of the generated types file that explains what compatibility data was used in its generation, for future optimisations. Something like // Auto generated runtime types: workerd@1.20240101.0 /20230102+global_navigator
// Generated by Wrangler on Thu Mar 28 2024 11:27:36 GMT+0000 (Greenwich Mean Time) | ||
// by running `wrangler types` | ||
// Generated by Wrangler on Mon Jul 22 2024 10:41:44 GMT+0200 (Central European Summer Time) | ||
// by running `wrangler types --x-with-runtime` |
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.
Would be great if this file was reproducible without a diff each time wrangler types
was run.
Is the timestamp necessary? I think @penalosa's idea of using the workerd version and compat date+flags would work better
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.
Yes, I like that better. Not sure why we have the timestamp.
Unless it's specifically to create a diff? Maybe we're undoing a specific decision by removing it.
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.
Looking back through the history, and the original PR that introduced this, there doesn't seem to be a specific reason to keep it.
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.
throw new Error(text); | ||
} | ||
|
||
await mf.dispose(); |
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.
Can you call this in a try..finally so that the workerd instance is guaranteed to be killed if any unexpected errors occur
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 note about the flag name: –x-with-runtime
. Rather than "with" can we go with "include": --x-include-runtime
?
Can do! Is there any precedent for either option, or are we just choosing something that makes sense here? |
Just thinking about this becoming non-experimental and then on-by-default and then using this flag to disable the runtime types |
Just one thing to consider. I would naturally avoid encouraging people to use the |
* feat: add runtime type generation to wrangler types command chore: remove unused file chore: add changeset chore: remove unnecessary fixture chore: add try/catch to JSON.parse chore: update changeset chore: update changeset and isolate tests chore: revert pnpm lock changes * chore: update lock file * chore: re-add vitest config * chore: check for node compat, extract util file * chore: update node_compat logic and wording * chore: reuse node_compat logic * chore: revert order * chore: fix mode * chore: update e2e test * chore: dispose of Miniflare inside 'finally' block * chore: add more tests * chore: use --x-include-runtime instead of --x-with-runtime --------- Co-authored-by: Andy Jessop <ajessop@cloudflare.com>
This PR introduces dynamic runtime type generation, according to a user's project configuration. The feature is hidden behind an experimental flag (
--x-with-runtime
), so is added here as a minor version change.Why is this required?
User's can specify
compatibility_flag
s for their project, but our@cloudflare/workers-types
package does not take these into account. It only accounts for thecompatibility_date
, and users specify the entry point in theirtsconfig.json
'scompilerOptions.types
array, e.g. `"types": ["@cloudflare/workers-types/2024-01-01"]. Clearly we can't produce entry points for every possible combination of date and flags.What is the solution?
The
workerd
npm package now includes a worker (workerd/worker.mjs
) that accepts compatibility date and flags in the URL path, e.g.The response is a string of TS types that can be written to the filesystem for use in TS projects.
This PR hooks up
wrangler types --x-with-runtime
to this type-generating worker, providing it with the config from the user's project, and saving either to a default location:Or to a specified location:
Note that the default location is inside the
.wrangler
hidden folder, so this file will not be committed by default. In order to commit this file, the user can specify a location that is not ignored by git.Advice is given in the console to:
Author has addressed the following