Scheduled Worker

[enri90]

Is support for Cloudflare Workers scheduled handlers planned in Vike?

For example, I’d like to export a Worker compatible with both Vike’s Server type and Cloudflare’s scheduled events:

import type { Server } from "vike/types";
import { app } from "./server/hono";

const port = process.env.PORT ? parseInt(process.env.PORT, 10) : 3000;

export default {
	fetch: app.fetch,
	async scheduled(event, env, ctx) {
          console.log(`Scheduled event triggered at: ${new Date(event.scheduledTime)}`)
          // Add your scheduled logic here
    },
	prod: {
		port,
	},
} satisfies Server;

Is there an officially supported way to add this today, or is support for it planned?

[sambai-dev]

Short version: nothing in Vike blocks this today. The type system already accepts your snippet, and Vike's build pipeline deliberately passes named exports through. The only open question is whether the last link in the chain, the Cloudflare Vite plugin's generated worker wrapper, preserves them into the deployed worker. That part I have not verified, and there is a two-minute way to find out.

What I checked in source:

1. Types. Server in packages/vike/src/types/Server.ts is interface Server extends Fetchable, and Fetchable in @universal-deploy/store is just { fetch: (request: Request) => Response | Promise<Response> }. There is no closed field list, and since satisfies (unlike a plain type annotation) tolerates excess properties, your object with fetch plus a scheduled method type-checks as-is against current releases.

2. Build pipeline. When a +server entry exists, pluginServerEntryAlias.ts wraps the userland entry with export * from <your server file> next to the re-exported default, with the comment "Also re-export non-default exports, to support Durable Objects". So Vike intentionally forwards named runtime handlers like scheduled; Durable Object classes already rely on exactly this mechanism. For Cloudflare specifically, pluginUniversalDeploy.ts special-cases @cloudflare/vite-plugin as the deployment target, meaning the final worker-entry generation belongs to Cloudflare's plugin, not to Vike.

3. The unverified link. Whether Cloudflare's Vite plugin preserves arbitrary named exports through its own generated wrapper is what decides if scheduled actually fires. Worth confirming before relying on it:

npx vitest run # after adding a test that imports your built entry
# or simply: npx wrangler dev, then curl the __scheduled endpoint
# wrangler dev exposes GET /__scheduled?cron=... to trigger the handler

If the export survives, you are done; crons go in wrangler.jsonc under triggers.crons. If it does not survive, that is worth a feature discussion in the Vike repo, because nothing in the public types reserves or forbids scheduled today.

The zero-coupling alternative that works regardless: deploy a separate tiny cron Worker (its own script and triggers.crons in its own wrangler config) that calls an internal endpoint on the app. Decoupled from Vike's entry handling entirely, at the cost of one more deployment.

Sources:

• https://github.com/vikejs/vike/blob/main/packages/vike/src/types/Server.ts
• https://github.com/vikejs/vike/blob/main/packages/vike/src/node/vite/plugins/pluginUniversalDeploy/pluginServerEntryAlias.ts
• https://github.com/photon-js/universal-deploy/blob/main/packages/store/src/types.ts

[brillout]

I confirm, we designed it so that exports are forwarded.

[enri90]

Thanks so much for the detailed breakdown @sambai-dev, and for confirming it @brillout 🙏

Can confirm the exports do get forwarded all the way through to the final worker. I verified it by applying exactly this approach: instead of typing the handler with my own custom type (risking fetch/scheduled drifting out of sync with Cloudflare's real APIs), I use vike:server-entry for fetch and let ExportedHandler — the official type from @cloudflare/workers-types — validate the whole object via satisfies:

worker.ts

import vikeServer from "vike:server-entry";

export default {
  fetch: vikeServer.fetch,
  scheduled(controller, env, ctx) {
     ctx.waitUntil(
     // ...
  },
} satisfies ExportedHandler<Env>;

wrangler.jsonc

{
  "main": "worker.ts"
}

This way scheduled (and its controller, env, ctx params) gets typed correctly by Cloudflare itself, not by some parallel definition of my own, and satisfies still leaves me free to add fetch/scheduled without TypeScript complaining about "excess" properties relative to Vike's Server. Everything works fine in wrangler dev, and the crons fire correctly from wrangler.jsonc (triggers.crons), exactly as described above.