Config Types

Tamer exports TypeScript types for the Tamer config (tamer/project.config.ts) and for Wrangler configs (generated from the official Wrangler config schema). Use them to author both with full type safety.

Usage

Tamer config

import {
  cf,
  defineConfig,
  type WorkerConfig,
  type EnvOverride,
  type WfpConfig,
  type WfpNamespaceConfig,
  type WfpWorkerTemplate,
} from "@dragonmastery/tamer";

export default defineConfig({
  stack: "my-app",
  compatibility_date: "2025-05-19",
  workers: {
    api: { /* WorkerConfig */ } satisfies WorkerConfig,
  },
  wfp: {
    ephemeralEnvPattern: "^pr-",
    tenantDirectory: {
      worker: "dispatch",
      shardGroup: "directory",
      service: "tenant",
    },
    namespaces: {
      myapp: {
        workers: {
          tenant: {
            main: "apps/tenant/src/index.ts",
            shardGroups: [
              { name: "primary", binding: "DB", migrationsDir: "db/primary/migrations" },
            ],
            d1: [
              { logicalName: "system", binding: "DB_SYSTEM", migrationsDir: "db/system/migrations" },
            ],
            vars: { APP_NAME: "MyApp" },
            services: [{ binding: "API", service: "${tamer:worker:api.name}" }],
            secrets: ["JWT_SECRET"],
          } satisfies WfpWorkerTemplate,
        },
      } satisfies WfpNamespaceConfig,
    },
  } satisfies WfpConfig,
});

Wrangler config

import type {
  WranglerConfig,
  WranglerEnvironment,
  WranglerD1Database,
  WranglerR2Bucket,
  WranglerKVNamespace,
} from "@dragonmastery/tamer";

const config: WranglerConfig = {
  name: "my-worker",
  main: "src/index.ts",
  compatibility_date: "2025-01-01",
  d1_databases: [{ binding: "DB", database_id: "xxx" }],
};

Exported types

Tamer config types

Type	Description
TamerConfig	Root document (defineConfig return type). Union of TamerConfigSingle / TamerConfigMulti.
TamerConfigSingle	Single-worker stack (worker field).
TamerConfigMulti	Multi-worker stack (workers map).
TamerConfigBase	Shared root fields: stack, account_id, compatibility_date, naming, wfp, protectedEnvs, dnsRecords, logpushJobs, outputs, codegen.
WorkerConfig	A worker entry under workers (or top-level worker).
EnvOverride	Shape of env.<name> and local override blocks.
NamingConventions	Optional naming hooks (d1Single, d1Shard, r2Bucket, workerName, workflow).
WfpConfig	wfp block: { namespaces, ephemeralEnvPattern?, tenantDirectory? }.
WfpNamespaceConfig	One dispatch namespace per product: { workers: Record<service, WfpWorkerTemplate>, namespace? }. Default CF namespace name is {product}-{env}.
WfpWorkerTemplate	Per-service tenant Worker template: wrangler passthrough (kv_namespaces, queues, worker_loaders, …) plus { main, path?, shardGroups?, d1?, vars?, services?, secrets?, durableObjects?, doMigrations?, r2Groups?, local?, env? }. local / env.<name> overlays merge like stack workers (for local wrangler.json gen and remote deploy). Each workspace gets one script named {service}-{workspace}-{env}. Deployed via wrangler deploy --dispatch-namespace.
ShardGroupConfig	Append-only horizontal sharding: { name, binding, migrationsDir, migrationsTable?, seedDir? }. Shard N binds as {binding}_{NNN} (e.g. DB_000). Used on resources.shardGroups[] (stack) and WfpWorkerTemplate.shardGroups[] (tenant).
PerTenantD1Config	Non-sharded per-tenant utility D1: { logicalName, binding, migrationsDir?, migrationsTable?, seedDir? }.
WfpTenantDirectoryConfig	{ worker, shardGroup, service?, blockSize? } — maps dense tenantNumber → dispatch script name in a stack-level directory shard group.
D1ResourceConfig	Entry under resources.d1[].
R2ResourceConfig	Entry under resources.r2[].

Wrangler types

Type	Description
WranglerConfig	Full wrangler config (alias: RawConfig)
WranglerEnvironment	Environment block (alias: RawEnvironment)
WranglerD1Database	D1 binding entry
WranglerR2Bucket	R2 binding entry
WranglerKVNamespace	KV binding entry

Derived name patterns

When no naming hook or per-resource cloudflareName override is set, Tamer derives Cloudflare names from the logical name + env (the stack identity is available to hooks but not embedded in defaults):

Resource	Default name
D1 single	db_{logical}_{env}
D1 sharded	db_{logical}_{YYYYMMDD}_{env}
R2 bucket	r2-{logical}-{env}
KV namespace	kv_{logical}_{env}
Queue	q-{logical}-{env}
Hyperdrive	hd-{logical}-{env}
Vectorize	vec-{logical}-{env}
AI Gateway	aigw-{logical}-{env}
Pipeline	pipe-{logical}-{env}
Workflow	wf-{logical}-{env}
Secrets Store	sec-{logical}-{env}
Worker script	{stack}-{workerKey}-{env} (local omits -{env})
Dispatch namespace	{product}-{env} (from wfp.namespaces)
Tenant dispatch script	{service}-{workspace}-{env}
Shard group physical (stack)	db_{group}_{NNN}_{stack}_{env} → binding {prefix}_{NNN}
Shard group physical (tenant)	db_{group}_{NNN}_{product}_{workspace}_{env} → binding {prefix}_{NNN}
Per-tenant utility D1	db_{logicalName}_{product}_{workspace}_{env}

How Wrangler types are generated

Wrangler types are generated from Wrangler's config-schema.json via scripts/generate-wrangler-types.ts. The schema is fetched from unpkg (pinned via WRANGLER_SCHEMA_VERSION, or local via WRANGLER_SCHEMA_PATH).

Output: src/generated/wrangler-types.generated.ts — never hand-edit. Regenerate with bun run generate:wrangler-types.