@zerotal/inertia 1.13.4 → 1.13.5

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/CHANGELOG.md CHANGED
@@ -8,6 +8,31 @@ follows the Zerotal monorepo's unified versioning.
8
8
 
9
9
  ## [Unreleased]
10
10
 
11
+ ## [1.13.5] — 2026-09-01
12
+
13
+ ### Fixed
14
+
15
+ - **`inertia.ssr: true` now actually server-renders.** The flag registered `POST /__ssr`
16
+ and nothing in the request path consulted it, so an app that set it — and read the
17
+ documentation, which said the server renders the component into the template — got
18
+ exactly the empty root it had before.
19
+
20
+ `Inertia.render()` renders the component into the root, injects the page's `<Head>` into
21
+ the served `<head>`, and marks the root `data-server-rendered`. The scaffolded `app.tsx`
22
+ already hydrated on that attribute, so the client half needed no change: an app turns SSR
23
+ on with one config line and nothing else.
24
+
25
+ Server rendering was previously reachable only by rewriting each route to
26
+ `Inertia.stream()`, one call site at a time, which is not what a global switch means. An
27
+ app that did that can go back to `render()`.
28
+
29
+ A component that fails to render falls back to the client-rendered document with a
30
+ warning rather than failing the route: the page still works in a browser, and taking a
31
+ route down because an _optimisation_ failed would make `ssr: true` a liability.
32
+
33
+ `POST /__ssr` is unchanged and stays documented for what it is — the contract for an
34
+ external renderer, not the in-process switch.
35
+
11
36
  ## [1.13.2] — 2026-08-31
12
37
 
13
38
  ### Fixed
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@zerotal/inertia",
3
- "version": "1.13.4",
3
+ "version": "1.13.5",
4
4
  "license": "MIT",
5
5
  "maturity": "stable",
6
6
  "private": false,
@@ -34,7 +34,7 @@
34
34
  "typecheck": "tsc --noEmit"
35
35
  },
36
36
  "dependencies": {
37
- "@zerotal/core": "1.13.4"
37
+ "@zerotal/core": "1.13.5"
38
38
  },
39
39
  "peerDependencies": {
40
40
  "react": "^18 || ^19",
package/src/inertia.ts CHANGED
@@ -464,14 +464,12 @@ async function _renderedHtml(component: string, pageObject: PageObject): Promise
464
464
  const { modPath, framework } = await resolvePageModule(_getPagesDir(), component);
465
465
  const { body, head } = await renderInertiaPage(pageObject, modPath, framework);
466
466
 
467
- return (
468
- injectHead(prefix, head) +
469
- pageScript(pageObject) +
470
- rootOpen(true) +
471
- body +
472
- ROOT_CLOSE +
473
- suffix
474
- );
467
+ // `body` is already the whole mount root — `renderInertiaPage` returns
468
+ // `pageScript + rootOpen + html + ROOT_CLOSE` for React, and Vue's SSR result
469
+ // carries its own root too. Wrapping it again emits two `<div id="app">` and
470
+ // two `data-page` scripts, and the client hydrates against the wrong one.
471
+ // Composed exactly as `inertiaStream` composes it, so the two cannot drift.
472
+ return injectHead(prefix, head) + body + suffix;
475
473
  } catch (error) {
476
474
  console.warn(
477
475
  `[Inertia] SSR render failed for "${component}", serving the client-rendered ` +