| [ Web Proxy ] |
| Viewing: https://developers.cloudflare.com/workers/languages/typescript/ | [Back] [Original] |
TypeScript is a first-class language on Cloudflare Workers. All APIs provided in Workers are fully typed, and type definitions are generated directly from workerd , the open-source Workers runtime.
We recommend you generate types for your Worker by running wrangler types. Cloudflare also publishes type definitions to GitHub and npm (npm install -D @cloudflare/workers-types).
Version 5 and later
@cloudflare/workers-types version 5 exposes only the latest runtime types. The dated entrypoints, such as @cloudflare/workers-types/2022-11-30, are removed. Import from @cloudflare/workers-types for the latest stable types, or from @cloudflare/workers-types/experimental for APIs behind experimental compatibility flags. To match types to a specific compatibility date and flags, run wrangler types.
Generate types that match your Worker's configuration
Cloudflare continuously improves workerd , the open-source Workers runtime. Changes in workerd can introduce JavaScript API changes, thus changing the respective TypeScript types.
This means the correct types for your Worker depend on:
rules.For example, the runtime will only allow you to use the AsyncLocalStorage class if you have compatibility_flags = ["nodejs_als"] in your Wrangler configuration file. This should be reflected in the type definitions.
To ensure that your type definitions always match your Worker's configuration, you can dynamically generate types by running:
npx wrangler typesyarn wrangler typespnpm wrangler typesSee the wrangler types command docs for more details.
Note
If you are running a version of Wrangler that is greater than 3.66.0 but below 4.0.0, you will need to include the --experimental-include-runtime flag. During its experimental release, runtime types were output to a separate file (.wrangler/types/runtime.d.ts by default). If you have an older version of Wrangler, you can access runtime types through the @cloudflare/workers-types package.
This will generate a d.ts file and (by default) save it to worker-configuration.d.ts. This will include Env types based on your Worker bindings and runtime types based on your Worker's compatibility date and flags.
You should then add that file to your tsconfig.json's compilerOptions.types array. If you have the nodejs_compat compatibility flag, you should also install @types/node.
You can commit your types file to git if you wish.
Note
To ensure that your types are always up-to-date, make sure to run wrangler types after any changes to your config file.
Migrating from @cloudflare/workers-types to wrangler types
We recommend you use wrangler types to generate runtime types, rather than using the @cloudflare/workers-types package, as it generates types based on your Worker's compatibility date and compatibility flags, ensuring that types match the exact runtime APIs made available to your Worker.
Note
There are no plans to stop publishing the @cloudflare/workers-types package, which will still be the recommended way to type libraries and shared packages in the workers environment.
npm uninstall @cloudflare/workers-typesyarn remove @cloudflare/workers-typespnpm remove @cloudflare/workers-typesbun remove @cloudflare/workers-typesnpx wrangler typesyarn wrangler typespnpm wrangler typesThis will generate a .d.ts file, saved to worker-configuration.d.ts by default. This will also generate Env types. If for some reason you do not want to include those, you can set --include-env=false.
You can now remove any imports from @cloudflare/workers-types in your Worker code.
Note
If you are running a version of Wrangler that is greater than 3.66.0 but below 4.0.0, you will need to include the --experimental-include-runtime flag. During its experimental release, runtime types were output to a separate file (.wrangler/types/runtime.d.ts by default). If you have an older version of Wrangler, you can access runtime types through the @cloudflare/workers-types package.
{
"compilerOptions": {
"types": ["./worker-configuration.d.ts"]
}
}
Note that if you have specified a custom path for the runtime types file, you should use that in your compilerOptions.types array instead of the default path.
nodejs_compat (Optional)If you are using the nodejs_compat compatibility flag, you should also install @types/node.
npm i @types/nodeyarn add @types/nodepnpm add @types/nodebun add @types/nodeThen add this to your tsconfig.json.
{
"compilerOptions": {
"types": ["./worker-configuration.d.ts", "node"]
}
}
Regardless of your specific framework or build tools, you should run the wrangler types command before any tasks that rely on TypeScript.
Most projects will have existing build and development scripts, as well as some type-checking. In the example below, we're adding the wrangler types before the type-checking script in the project:
{
"scripts": {
"dev": "existing-dev-command",
"build": "existing-build-command",
"generate-types": "wrangler types",
"type-check": "generate-types && tsc"
}
}
We recommend you commit your generated types file for use in CI. You can run wrangler types before other CI commands, as it should not take more than a few seconds. For example:
- run: npm run generate-types
- run: npm run build
- run: npm test- run: yarn generate-types
- run: yarn build
- run: yarn test- run: pnpm run generate-types
- run: pnpm run build
- run: pnpm testAlternatively, if you commit your generated types file and want to verify it stays up-to-date in CI, you can use the --check flag:
- run: npx wrangler types --check
- run: npm run build
- run: npm test- run: yarn wrangler types --check
- run: yarn build
- run: yarn test- run: pnpm wrangler types --check
- run: pnpm run build
- run: pnpm testThis fails the CI job if the committed types file is out-of-date, prompting developers to regenerate and commit the updated types.
| Web Proxy Viewer | New URL | Original Page |