@decocms/tanstack 7.8.0 → 7.9.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@decocms/tanstack",
-  "version": "7.8.0",
+  "version": "7.9.0",
   "type": "module",
   "description": "Deco framework binding for TanStack Start + Cloudflare Workers",
   "repository": {
@@ -24,9 +24,9 @@
     "lint:unused": "knip"
   },
   "dependencies": {
-    "@decocms/blocks": "7.8.0",
-    "@decocms/blocks-admin": "7.8.0",
-    "@decocms/blocks-cli": "7.8.0",
+    "@decocms/blocks": "7.9.0",
+    "@decocms/blocks-admin": "7.9.0",
+    "@decocms/blocks-cli": "7.9.0",
     "@deco-cx/warp-node": "^0.3.16",
     "fast-json-patch": "^3.1.0",
     "ws": "^8.18.0"

package/src/vite/plugin.js

@@ -205,6 +205,16 @@ export function decoVitePlugin() {
       // runtime without any module invalidation (which breaks TanStack
       // Start/Router state).
       //
+      // NOTE: @decocms/nextjs takes the opposite approach — a generated
+      // static-import manifest (blocks-cli's generate-blocks-manifest.ts,
+      // wired as `createNextSetup({ blocks, blocksDir: false })`) that makes
+      // the bundler's own module-graph invalidation the content-reload
+      // mechanism. That design is deliberately NOT used here: a spike on
+      // TanStack Start 1.166 × @cloudflare/vite-plugin showed ANY SSR module
+      // invalidation bricks the router (the pre-existing upstream bug called
+      // out above), so this plugin's no-invalidation delta machinery below
+      // stays the TanStack dev-reload path until that's fixed upstream.
+      //
       // Generator is loaded lazily via tsImport (same pattern as the daemon
       // below) so we don't depend on the consumer's TS loader.
       const cwd = process.cwd();