Files
2026-08-22 18:55:46 +01:00

8.9 KiB

AGENTS.md

This file helps AI coding agents work effectively in the Cloudflare Workers SDK monorepo. Prefer authoritative configuration and documentation over copying details into this file: copied versions, rule lists, and counts become stale.

Start Here

  • Use pnpm, not npm or yarn.
  • Use the Node.js and pnpm versions declared in package.json.
  • Install dependencies with pnpm install.
  • Run commands from the workspace root unless package documentation says otherwise.
  • Before changing a package, read its AGENTS.md if it has one.
  • Do not edit generated files directly. Change their source or generator and regenerate them.

Common Commands

The root package.json is authoritative for available scripts.

  • pnpm build — build the workspace with Turbo.
  • pnpm test:ci — run tests in CI mode.
  • pnpm test:e2e — run end-to-end tests; many require Cloudflare credentials.
  • pnpm check — run the repository's validation, lint, type, and format checks.
  • pnpm fix — apply supported lint and formatting fixes.
  • pnpm prettify — format files with oxfmt.
  • pnpm run <script> --filter <package> — run a Turbo task for one package.
  • pnpm -w test:ci -F <package> -- <test-file> — run a package's specific test file when its test configuration supports it.

Prefer the narrowest relevant test while developing, then run the broader package checks appropriate to the change. Do not run credentialed E2E tests unless the task and environment support them.

Repository Map

Task Location Notes
Add or modify a Wrangler command packages/wrangler/src/ Commands are registered from src/index.ts.
Change local development behavior packages/miniflare/src/ src/index.ts contains the main Miniflare class.
Modify embedded runtime workers packages/miniflare/src/workers/ Worker scripts use worker: virtual imports.
Change project scaffolding packages/create-cloudflare/ Templates and framework support live here.
Change the Vite integration packages/vite-plugin-cloudflare/ Includes package-specific playgrounds.
Change the Vitest integration packages/vitest-plugin/ Vitest integration for tests running in workerd.
Change shared config handling packages/workers-utils/src/config/ Shared types, normalization, and validation.
Use shared test helpers packages/workers-utils/src/test-helpers/ Includes temporary-directory and console helpers.
Change deploy or versions-upload validation packages/deploy-helpers/src/deploy/helpers/validate-worker-props.ts Keep deploy and versions-upload behavior aligned.
Add a fixture fixtures/ Fixtures are workspace members with their own package.json.
Change CI .github/workflows/ test-and-check.yml is the main test workflow.
Change deployment tooling tools/deployments/ Scripts run directly through esbuild-register.
Create a changeset .changeset/README.md Read this file before deciding whether one is required.

Turbo orchestrates workspace tasks. Shared TypeScript configuration lives in packages/workers-tsconfig/; lint and formatting behavior is defined by .oxlintrc.jsonc, .oxfmtrc.jsonc, and packages/lint-config-shared/.

Cross-Tool Development Features

Wrangler, the Vite plugin, and the Vitest plugin are all consumers of the Workers development platform. A development feature is not complete merely because it works through one of them.

Implement development features in Miniflare wherever possible so that every consumer benefits from the same behavior. Keep the integration layers in Wrangler, the Vite plugin, and the Vitest plugin thin instead of implementing equivalent behavior independently in each tool. If Miniflare is not the appropriate layer, put shared behavior in the lowest suitable shared package.

When adding or changing development functionality:

  • assess its impact on Miniflare, Wrangler, the Vite plugin, and the Vitest plugin;
  • update shared configuration types, validation, and runtime behavior where applicable;
  • add coverage at the shared implementation layer; add consumer-specific tests when the consumer's integration or behavior is affected;
  • document intentional differences or unsupported consumers in the change and pull request.

Implementation Conventions

The checked-in configuration is authoritative. Run pnpm check rather than relying on a duplicated list of every enforced rule. In particular:

  • Keep TypeScript strictly typed. Avoid any, non-null assertions, and floating promises.
  • Use type-only imports where appropriate and node: prefixes for Node.js built-ins.
  • Prefer function declarations for named or exported functions.
  • Add well-formatted JSDoc to exported or public functions and to functions whose purpose is not evident, including useful tags such as @param and @returns where appropriate.
  • Comments should explain why; do not add comments that merely restate code.
  • Lint-disable comments require a reason after --.
  • In Wrangler, use the logger rather than calling console.* directly, except inside the logger implementation.
  • Use the Cloudflare TypeScript SDK rather than adding direct REST API calls.
  • Import ci-info through its default export.

oxfmt determines whitespace, quoting, import order, and package.json sorting. Do not reproduce those rules manually; run pnpm prettify.

Dependencies and Security

  • Packages normally bundle their dependencies. The repository validator in tools/deployments/validate-package-dependencies.ts is authoritative.
  • A package that must leave a dependency external declares it in that package's scripts/deps.ts as part of EXTERNAL_DEPENDENCIES, with an explanation.
  • After changing dependencies, run pnpm install so that the lockfile is updated.
  • Do not build shell commands with interpolated or concatenated untrusted input. The custom workers-sdk/no-unsafe-command-execution oxlint rule enforces the repository's command-execution constraints.

Testing Conventions

  • Use Vitest for unit and integration tests.
  • Use fixtures for filesystem and Worker scenarios; treat fixtures as user-facing examples and keep them clear and realistic.
  • Use the Vitest plugin when behavior must be tested in workerd.
  • In Vitest tests, obtain expect from the test context rather than importing it from vitest. Pass ExpectStatic to helpers that need it; use node:assert where test context is unavailable.
  • Prefer runInTempDir() and real filesystem operations over filesystem mocks.
  • Use mockConsoleMethods() to capture output and assert against its out, err, and warn properties.
  • Update relevant snapshots when changing user-facing output.
  • New examples under fixtures/vitest-plugin-examples/ need a tsconfig.json.

The shared defaults are defined in vitest.shared.ts; package configurations may override them.

Changes and Pull Requests

  • Work on a branch rather than committing directly to main.
  • Read .changeset/README.md to determine whether a changeset is required and how to write it. Do not assume every package-code change needs one.
  • Use .github/PULL_REQUEST_TEMPLATE.md when preparing a pull request.
  • The PR description requirements are enforced by tools/deployments/validate-pr-description.ts; treat that validator and the template as authoritative.
  • Use the repository's established [package] description PR-title style.
  • Run the relevant tests and checks locally before pushing.

Package-Specific Guidance

Many packages provide their own AGENTS.md. Locate and read the closest applicable file before making changes. When a change makes guidance inaccurate, update that file in the same change. Put package-specific knowledge in the package's file; keep this root file focused on repository-wide workflow and navigation.