src/presets/vercel/runtime/vercel.node.ts (1)

5-22: Node runtime ISR rewrite correctly centralized via isrRouteRewrite

The node handler’s ISR handling now mirrors the web runtime and cleanly delegates URL extraction to isrRouteRewrite, which is a good consolidation of logic. The req.url! assertion and use of the x-now-route-matches header align with prior behavior, so no functional regressions are apparent here.

If you want to tighten the types a bit, you could consider passing null explicitly when the header is missing instead of casting to string, but that’s purely cosmetic:

-  const isrURL = isrRouteRewrite(
-    req.url!,
-    req.headers["x-now-route-matches"] as string
-  );
+  const isrURL = isrRouteRewrite(
+    req.url!,
+    (req.headers["x-now-route-matches"] as string | undefined) ?? null
+  );

src/presets/vercel/utils.ts (2)

13-239: ISR route rule generation looks consistent; double‑check behavior for non‑/** ISR routes

Using ISR_URL_PARAM for both the named capture and the dest query is a nice improvement and keeps the runtime and build config in sync. The transformations

• root / rule:
  • src: (?<__isr_route>/)
  • dest: /index-isr?__isr_route=$__isr_route
• catch‑all ISR rules:
  • src via key.replace(/^(.*)\/\*\*/, '(?<__isr_route>$1/.*)')
  • dest via ...?__isr_route=$__isr_route

are all coherent and match the expectations encoded in the updated tests.

One corner case worth verifying: if someone defines routeRules["/foo"]!.isr without a /** suffix, src will stay as "/foo" (no named capture), but dest will still reference $__isr_route. That relies on Vercel’s routing engine to either (a) provide a __isr_route entry in x-now-route-matches even without an explicit named group, or (b) treat $__isr_route in dest in a forgiving way. If this scenario is not supported or guaranteed, it may be safer to either:

• require /** for ISR rules that depend on __isr_route, or
• synthesize a named group for non‑/** ISR rules as well.

Please confirm this behavior against the Vercel Build Output API docs / runtime behavior for non‑/** ISR routes that still use $__isr_route in dest.

---

482-487: Ensuring __isr_route is in allowQuery is good; consider avoiding in‑place mutation

The allowQuery augmentation correctly guarantees that __isr_route is forwarded when a user has explicitly set allowQuery, which is important for ISR revalidation flows.

Right now this mutates the allowQuery array in place, which is likely the same array referenced by the original route rule config. That’s probably fine given Nitro already mutates route rules elsewhere, but if you want to keep user config more obviously immutable, you could reassign a cloned array instead:

-  if (
-    prerenderConfig.allowQuery &&
-    !prerenderConfig.allowQuery.includes(ISR_URL_PARAM)
-  ) {
-    prerenderConfig.allowQuery.push(ISR_URL_PARAM);
-  }
+  if (prerenderConfig.allowQuery) {
+    if (!prerenderConfig.allowQuery.includes(ISR_URL_PARAM)) {
+      prerenderConfig.allowQuery = [
+        ...prerenderConfig.allowQuery,
+        ISR_URL_PARAM,
+      ];
+    }
+  }

src/presets/vercel/runtime/isr.ts (1)

1-23: Centralized ISR URL extraction is solid; avoid trailing ? when no extra query remains

The ISR_URL_PARAM constant and isrRouteRewrite helper nicely centralize ISR URL extraction logic for both runtimes, and the query‑string fallback correctly strips __isr_route while preserving other query params.

There is a small edge case in the query‑based branch: if __isr_route is the only query parameter, params.toString() returns an empty string, so the function returns a URL like "/some/path?" instead of "/some/path". Functionally it’s usually fine, but it’s easy to avoid and keeps URLs cleaner:

-      const params = new URLSearchParams(reqUrl.slice(queryIndex + 1));
-      const isrURL = params.get(ISR_URL_PARAM);
-      if (isrURL) {
-        params.delete(ISR_URL_PARAM);
-        return decodeURIComponent(isrURL) + "?" + params.toString();
-      }
+      const params = new URLSearchParams(reqUrl.slice(queryIndex + 1));
+      const isrURL = params.get(ISR_URL_PARAM);
+      if (isrURL) {
+        params.delete(ISR_URL_PARAM);
+        const restQuery = params.toString();
+        const decoded = decodeURIComponent(isrURL);
+        return restQuery ? `${decoded}?${restQuery}` : decoded;
+      }

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

src/presets/vercel/runtime/vercel.node.ts (1)

15-24: ISR rewrite logic is sound; consider a small readability tweak

The flow—derive an ISR target via isrRouteRewrite, check getRouteRules("", pathname) for routeRules?.isr, and only then rewrite req.url—is correct and safely no‑ops when there is no applicable ISR rule.

For readability and to avoid magic tuple indices, you could optionally destructure the result:

-  const isrURL = isrRouteRewrite(
-    req.url!,
-    req.headers["x-now-route-matches"] as string
-  );
-  if (isrURL) {
-    const { routeRules } = getRouteRules("", isrURL[0]);
-    if (routeRules?.isr) {
-      req.url = isrURL[0] + (isrURL[1] ? `?${isrURL[1]}` : "");
-    }
-  }
+  const isrURL = isrRouteRewrite(
+    req.url!,
+    req.headers["x-now-route-matches"] as string
+  );
+  if (isrURL) {
+    const [pathname, search] = isrURL;
+    const { routeRules } = getRouteRules("", pathname);
+    if (routeRules?.isr) {
+      req.url = pathname + (search ? `?${search}` : "");
+    }
+  }

Behavior stays identical; the block becomes a bit clearer to future readers.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro