@solcreek/adapter-creek 0.2.3 → 0.2.5

package/dist/bundler.js

@@ -12,6 +12,7 @@ import * as path from "node:path";
 import { execFileSync } from "node:child_process";
 import { builtinModules, createRequire } from "node:module";
 import { fileURLToPath } from "node:url";
+import { WORKER_COMPATIBILITY_DATE, WORKER_COMPATIBILITY_FLAGS } from "./compat.js";
 /**
  * Resolve wrangler's CLI entry script through Node module resolution.
  *
@@ -676,8 +677,8 @@ export async function bundleForWorkers(opts) {
     const wranglerConfig = {
         name: "creek-adapter-build",
         main: entryPath,
-        compatibility_date: "2026-03-28",
-        compatibility_flags: ["nodejs_compat"],
+        compatibility_date: WORKER_COMPATIBILITY_DATE,
+        compatibility_flags: [...WORKER_COMPATIBILITY_FLAGS],
         define: {
             __dirname: '""',
             __filename: '""',

package/dist/compat.d.ts

@@ -0,0 +1,21 @@
+/**
+ * Single source of truth for the compatibility settings the generated
+ * worker is built AND deployed with.
+ *
+ * The Next.js worker statically imports node:http (server APIs). Per
+ * Cloudflare's Node.js docs, node:http is served by the umbrella
+ * `nodejs_compat` flag (NOT `nodejs_compat_v2`, which the docs no longer
+ * list and which WfP rejects for node:http). Its SERVER modules
+ * (`http.createServer`/`Server`/`ServerResponse`) are gated behind
+ * `enable_nodejs_http_server_modules`, auto-enabled only at
+ * compatibility_date >= 2025-09-01 (client APIs at 2025-08-15). This is why
+ * a 2025-03-14 deploy was rejected with "No such module node:http".
+ *
+ * The bundle step (bundler.ts) and the deploy manifest (manifest.ts) MUST
+ * agree: the worker is validated at upload against the date/flags it ships
+ * with, so the deploy must use exactly what the bundle was built against.
+ * Keep DATE >= 2025-09-01.
+ */
+export declare const WORKER_COMPATIBILITY_DATE = "2026-03-28";
+export declare const WORKER_COMPATIBILITY_FLAGS: readonly string[];
+//# sourceMappingURL=compat.d.ts.map

package/dist/compat.js

@@ -0,0 +1,21 @@
+/**
+ * Single source of truth for the compatibility settings the generated
+ * worker is built AND deployed with.
+ *
+ * The Next.js worker statically imports node:http (server APIs). Per
+ * Cloudflare's Node.js docs, node:http is served by the umbrella
+ * `nodejs_compat` flag (NOT `nodejs_compat_v2`, which the docs no longer
+ * list and which WfP rejects for node:http). Its SERVER modules
+ * (`http.createServer`/`Server`/`ServerResponse`) are gated behind
+ * `enable_nodejs_http_server_modules`, auto-enabled only at
+ * compatibility_date >= 2025-09-01 (client APIs at 2025-08-15). This is why
+ * a 2025-03-14 deploy was rejected with "No such module node:http".
+ *
+ * The bundle step (bundler.ts) and the deploy manifest (manifest.ts) MUST
+ * agree: the worker is validated at upload against the date/flags it ships
+ * with, so the deploy must use exactly what the bundle was built against.
+ * Keep DATE >= 2025-09-01.
+ */
+export const WORKER_COMPATIBILITY_DATE = "2026-03-28";
+export const WORKER_COMPATIBILITY_FLAGS = ["nodejs_compat"];
+//# sourceMappingURL=compat.js.map

package/dist/manifest.js

@@ -7,6 +7,7 @@
 import * as fs from "node:fs/promises";
 import * as path from "node:path";
 import { createRequire } from "node:module";
+import { WORKER_COMPATIBILITY_DATE, WORKER_COMPATIBILITY_FLAGS } from "./compat.js";
 const require = createRequire(import.meta.url);
 const adapterPackage = require("../package.json");
 export async function writeManifest(outputDir, opts) {
@@ -22,8 +23,8 @@ export async function writeManifest(outputDir, opts) {
         entrypoint: opts.entrypoint,
         serverFiles: opts.serverFiles,
         assetDir: "assets",
-        compatibilityDate: "2026-03-28",
-        compatibilityFlags: ["nodejs_compat_v2"],
+        compatibilityDate: WORKER_COMPATIBILITY_DATE,
+        compatibilityFlags: [...WORKER_COMPATIBILITY_FLAGS],
         hasMiddleware: opts.hasMiddleware,
         hasPrerender: opts.hasPrerender,
         // Always inject DO bindings for Next.js SSR (ISR cache support)

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@solcreek/adapter-creek",
-  "version": "0.2.3",
+  "version": "0.2.5",
   "description": "Next.js deployment adapter for Creek (Cloudflare Workers)",
   "type": "module",
   "main": "./dist/index.js",
@@ -45,6 +45,7 @@
   },
   "dependencies": {
     "@next/routing": "16.2.3",
+    "@node-rs/xxhash": "^1.7.6",
     "@solcreek/adapter-core": "^0.2.0",
     "@solcreek/adapter-next-core": "^0.1.1",
     "sql.js": "^1.14.1",
@@ -54,7 +55,6 @@
     "next": ">=16.2.3"
   },
   "devDependencies": {
-    "@node-rs/xxhash": "^1.7.6",
     "@types/node": "^22.13.10",
     "miniflare": "^4.20260410.0",
     "next": "16.2.3",