@lunora/nuxt 1.0.0-alpha.273 → 1.0.0-alpha.275

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/dist/module.json CHANGED
@@ -1,5 +1,5 @@
1
1
  {
2
2
  "configKey": "lunora",
3
3
  "name": "@lunora/nuxt",
4
- "version": "1.0.0-alpha.272"
4
+ "version": "1.0.0-alpha.274"
5
5
  }
@@ -1,3 +1,23 @@
1
+ /**
2
+ * Resolve the Cloudflare per-request `env` (bindings) and `ExecutionContext`
3
+ * from a Nitro/H3 event, tolerating the two shapes Nitro has shipped.
4
+ *
5
+ * Legacy `event.context.cloudflare.{ env, context }` — surfaced by
6
+ * `nitro-cloudflare-dev` in `nuxt dev` and by older `cloudflare_module` builds,
7
+ * where `context` is the `ExecutionContext` (`waitUntil` / `passThroughOnException`).
8
+ *
9
+ * Newer `event.req.runtime.cloudflare.{ env, ctx }` — the Nitro runtime accessor
10
+ * (Nitro v2.10+ / Nuxt 4), where the `ExecutionContext` is `ctx`.
11
+ *
12
+ * Both are read defensively so the delegating handler works across the version
13
+ * range a scaffolded app might pin, in both dev and the deployed worker. When
14
+ * neither is present (no Cloudflare runtime — e.g. a Node preview), `env` is
15
+ * `undefined` and the caller surfaces a clear error.
16
+ *
17
+ * Typed against a structural `H3EventLike` rather than `nitropack`'s `H3Event`
18
+ * so this seam stays pure (no Nitro types needed) and unit-testable with a plain
19
+ * object — a real `H3Event` is still assignable here.
20
+ */
1
21
  import { ExecutionContextLike } from '@lunora/runtime';
2
22
  export type { ExecutionContextLike } from '@lunora/runtime';
3
23
  /** The `{ env, context|ctx }` payload Nitro attaches for the Cloudflare runtime. */
@@ -1,3 +1,23 @@
1
+ /**
2
+ * Resolve the Cloudflare per-request `env` (bindings) and `ExecutionContext`
3
+ * from a Nitro/H3 event, tolerating the two shapes Nitro has shipped.
4
+ *
5
+ * Legacy `event.context.cloudflare.{ env, context }` — surfaced by
6
+ * `nitro-cloudflare-dev` in `nuxt dev` and by older `cloudflare_module` builds,
7
+ * where `context` is the `ExecutionContext` (`waitUntil` / `passThroughOnException`).
8
+ *
9
+ * Newer `event.req.runtime.cloudflare.{ env, ctx }` — the Nitro runtime accessor
10
+ * (Nitro v2.10+ / Nuxt 4), where the `ExecutionContext` is `ctx`.
11
+ *
12
+ * Both are read defensively so the delegating handler works across the version
13
+ * range a scaffolded app might pin, in both dev and the deployed worker. When
14
+ * neither is present (no Cloudflare runtime — e.g. a Node preview), `env` is
15
+ * `undefined` and the caller surfaces a clear error.
16
+ *
17
+ * Typed against a structural `H3EventLike` rather than `nitropack`'s `H3Event`
18
+ * so this seam stays pure (no Nitro types needed) and unit-testable with a plain
19
+ * object — a real `H3Event` is still assignable here.
20
+ */
1
21
  import { ExecutionContextLike } from '@lunora/runtime';
2
22
  export type { ExecutionContextLike } from '@lunora/runtime';
3
23
  /** The `{ env, context|ctx }` payload Nitro attaches for the Cloudflare runtime. */
@@ -1,3 +1,20 @@
1
+ /**
2
+ * The Lunora ↔ Nitro delegation seam. Given a Lunora worker (the
3
+ * `defineApp().build()` app or a bare `createWorker(...)` result) and the
4
+ * Cloudflare runtime resolved off the request event, forward the inbound
5
+ * `Request` — RPC (`POST /_lunora/rpc`), WebSocket upgrade (`/_lunora/ws`), and
6
+ * the admin plane (`/_lunora/admin/*`) — straight to `worker.fetch`.
7
+ *
8
+ * This is the single-worker composition the void.cloud Nuxt approach uses,
9
+ * inverted: instead of Lunora owning the worker entry, Lunora is mounted
10
+ * inside* Nitro as a server route, and the `ShardDO` class is re-exported to
11
+ * the Cloudflare worker entrypoint via the project's root `worker.ts` wrapper.
12
+ *
13
+ * Kept framework-neutral (a `LunoraWorkerLike` + the resolved `env`/`ctx`, not
14
+ * an H3 event) so it can be unit-tested with a stub worker — no Nuxt or workerd
15
+ * boot required. The thin H3 adapter that reads `env`/`ctx` off the event and
16
+ * the raw `Request`/`Response` lives in the `[...].ts` route module.
17
+ */
1
18
  import { ExecutionContextLike } from '@lunora/runtime';
2
19
  export { NOOP_EXECUTION_CONTEXT } from '@lunora/runtime';
3
20
  /**
@@ -1,3 +1,20 @@
1
+ /**
2
+ * The Lunora ↔ Nitro delegation seam. Given a Lunora worker (the
3
+ * `defineApp().build()` app or a bare `createWorker(...)` result) and the
4
+ * Cloudflare runtime resolved off the request event, forward the inbound
5
+ * `Request` — RPC (`POST /_lunora/rpc`), WebSocket upgrade (`/_lunora/ws`), and
6
+ * the admin plane (`/_lunora/admin/*`) — straight to `worker.fetch`.
7
+ *
8
+ * This is the single-worker composition the void.cloud Nuxt approach uses,
9
+ * inverted: instead of Lunora owning the worker entry, Lunora is mounted
10
+ * inside* Nitro as a server route, and the `ShardDO` class is re-exported to
11
+ * the Cloudflare worker entrypoint via the project's root `worker.ts` wrapper.
12
+ *
13
+ * Kept framework-neutral (a `LunoraWorkerLike` + the resolved `env`/`ctx`, not
14
+ * an H3 event) so it can be unit-tested with a stub worker — no Nuxt or workerd
15
+ * boot required. The thin H3 adapter that reads `env`/`ctx` off the event and
16
+ * the raw `Request`/`Response` lives in the `[...].ts` route module.
17
+ */
1
18
  import { ExecutionContextLike } from '@lunora/runtime';
2
19
  export { NOOP_EXECUTION_CONTEXT } from '@lunora/runtime';
3
20
  /**
@@ -1,3 +1,24 @@
1
+ /**
2
+ * Nitro server handler mounted at `/_lunora/**` by the `@lunora/nuxt` module
3
+ * (`addServerHandler`). It is the single-worker seam: every Lunora RPC,
4
+ * WebSocket upgrade, and admin request is forwarded to the project's Lunora
5
+ * worker, which runs *inside* the same Nitro/Cloudflare worker the rest of the
6
+ * Nuxt app deploys as.
7
+ *
8
+ * The worker instance is the project's composed app, imported through the
9
+ * `#lunora/app` virtual the module registers (it points at the app entry — by
10
+ * default `~/lunora/server`, where `defineApp().build()` lives and re-exports
11
+ * `ShardDO`). The same `ShardDO` is re-exported to the Cloudflare worker
12
+ * entrypoint via the project's root `worker.ts` wrapper (`wrangler.jsonc`'s
13
+ * `main`), so one deploy carries both the SSR handler and the Durable Object class.
14
+ *
15
+ * This file is only ever bundled by Nitro; `h3`'s `defineEventHandler` is its
16
+ * sole framework entry. We use a namespace import so the seam spans the h3
17
+ * v1 → v2 break: v1 exposes `toWebRequest(event)`, while the v2 web-standards
18
+ * rewrite removed it and carries the web `Request` directly as `event.req`. A
19
+ * static `import { toWebRequest }` would throw at module-eval under v2 (missing
20
+ * named export), so `resolveWebRequest` feature-detects it at runtime instead.
21
+ */
1
22
  import { QueryObject } from 'ufo';
2
23
  import { Hooks } from 'crossws';
3
24
  import { IncomingMessage, ServerResponse } from 'node:http';
@@ -1,3 +1,24 @@
1
+ /**
2
+ * Nitro server handler mounted at `/_lunora/**` by the `@lunora/nuxt` module
3
+ * (`addServerHandler`). It is the single-worker seam: every Lunora RPC,
4
+ * WebSocket upgrade, and admin request is forwarded to the project's Lunora
5
+ * worker, which runs *inside* the same Nitro/Cloudflare worker the rest of the
6
+ * Nuxt app deploys as.
7
+ *
8
+ * The worker instance is the project's composed app, imported through the
9
+ * `#lunora/app` virtual the module registers (it points at the app entry — by
10
+ * default `~/lunora/server`, where `defineApp().build()` lives and re-exports
11
+ * `ShardDO`). The same `ShardDO` is re-exported to the Cloudflare worker
12
+ * entrypoint via the project's root `worker.ts` wrapper (`wrangler.jsonc`'s
13
+ * `main`), so one deploy carries both the SSR handler and the Durable Object class.
14
+ *
15
+ * This file is only ever bundled by Nitro; `h3`'s `defineEventHandler` is its
16
+ * sole framework entry. We use a namespace import so the seam spans the h3
17
+ * v1 → v2 break: v1 exposes `toWebRequest(event)`, while the v2 web-standards
18
+ * rewrite removed it and carries the web `Request` directly as `event.req`. A
19
+ * static `import { toWebRequest }` would throw at module-eval under v2 (missing
20
+ * named export), so `resolveWebRequest` feature-detects it at runtime instead.
21
+ */
1
22
  import { QueryObject } from 'ufo';
2
23
  import { Hooks } from 'crossws';
3
24
  import { IncomingMessage, ServerResponse } from 'node:http';
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@lunora/nuxt",
3
- "version": "1.0.0-alpha.273",
3
+ "version": "1.0.0-alpha.275",
4
4
  "description": "Nuxt module for Lunora — single-worker composition (mounts /_lunora/* into Nitro) plus reactive-loader server helpers",
5
5
  "keywords": [
6
6
  "cloudflare",
@@ -51,8 +51,8 @@
51
51
  "access": "public"
52
52
  },
53
53
  "dependencies": {
54
- "@lunora/client": "1.0.0-alpha.253",
55
- "@lunora/runtime": "1.0.0-alpha.242",
54
+ "@lunora/client": "1.0.0-alpha.255",
55
+ "@lunora/runtime": "1.0.0-alpha.244",
56
56
  "@nuxt/kit": "^4.5.2"
57
57
  },
58
58
  "peerDependencies": {