workers-best-practices
Cloudflare Workers code review and authoring against production best practices.
- Retrieves latest Workers APIs, types, and wrangler configuration schema before reviewing or writing code; biases towards live documentation over pre-trained knowledge
- Covers 40+ best practice rules across configuration, request/response handling, architecture, observability, code patterns, and security
- Flags 15+ common anti-patterns including unbounded streaming, floating promises, global request state, hardcoded secrets, and unsafe crypto usage
- Provides structured review workflow: retrieve references, validate types and config, check patterns and security, validate with tools
Your knowledge of Cloudflare Workers APIs, types, and configuration may be outdated. Prefer retrieval over pre-training when writing or reviewing Workers code.
Use the project's installed versions, generated types, and Wrangler compatibility settings as the baseline for existing code. Retrieve relevant Cloudflare documentation to verify API, configuration, runtime behavior, and limit claims.
References
Read the sections relevant to the task:
| Reference | When to use it |
|---|---|
| Configuration and observability | Compatibility dates, bindings, generated types, secrets, logs, and traces |
| Runtime patterns | Streaming, promise lifetime, request state, service calls, security, and runtime tests |
| Platform API checks | Handler signatures, platform classes, binding access, and serialization |
For missing evidence, consult Workers best practices or find the affected product in the Cloudflare docs directory. Use the installed Wrangler schema for config fields. A newer type package does not supersede the project's configured target.
Keep Compatibility Dates Current
Use today's date for new Workers. Encourage periodic updates for existing Workers, reviewing compatibility changes and running relevant tests. Assess existing behavior against its configured date and flags; see compatibility guidance.