Under the hood Bindings

How Devflare wires Analytics Engine from config to runtime

Analytics Engine has a straightforward compiler story, plus a preview note that matters because datasets are auto-created on first write instead of provisioned like buckets or databases.

That is the core reason the docs should separate it from storage bindings: the worker env shape is familiar, but the resource lifecycle behaves differently.

Normalization: The authored shape is a simple dataset mapping; the interesting behavior is lifecycle, not deep normalization
Compile target: Wrangler
Preview note: Preview names can change, but Devflare does not provision or delete Analytics Engine datasets for you

Devflare normalizes the authored shape before it does anything louder

Analytics Engine bindings are a small schema surface: a binding name maps to a dataset name. That keeps authored config simple and predictable.

The more important implementation detail is that datasets are not managed like KV namespaces or buckets. They come to life on write, so preview lifecycle support looks different.

Analytics Engine from authored config to generated output

Keep the binding readable in source, then inspect only the Wrangler-facing slice Devflare emits when the config is compiled.

import { defineConfig } from 'devflare/config'

export default defineConfig({

name: 'analytics-worker',

bindings: {

analyticsEngine: {

APP_ANALYTICS: {

dataset: 'app-analytics'

}

})

Local runtime support depends on what Devflare can model directly

The repo smoke app and integration tests show being called through the binding, which is enough to describe the runtime contract honestly.
I did not find a dedicated analytics helper surface in the test harness, so docs should steer people toward thin worker tests or explicit mocks instead.
Type generation still matters here because it keeps the env contract clear even when the test story is lighter.

Compile, preview, and cleanup behavior

Compile emits dataset entries into Wrangler-facing output.
Preview materialization can rewrite dataset names, but Devflare intentionally does not try to provision or delete those datasets for you.
That lifecycle difference is the main caveat compared with storage or queue resources.

Name changes do not imply resource management

Preview-scoped naming is useful, but it does not mean Devflare owns the full dataset lifecycle the way it can for KV, D1, or queues.

Analytics Engine

Analytics Engine is modeled cleanly in Devflare config and generated types, but the repo evidence points to a lighter local story than the first-class storage bindings.

Testing Analytics Engine

Analytics Engine tests should stay thin: verify that the worker writes a data point, not that you can recreate Cloudflare analytics locally.