packages/nuxt/src/app/components/nuxt-layout.ts (2)

129-133: Prefer an explicit PropType over bare Function

Typing props with the generic PropType gives clearer IDE hints and prevents accidental misuse.

-  isRenderingNewLayout: {
-    type: Function as unknown as () => (name?: string | boolean) => boolean,
-    required: true,
-  },
+  isRenderingNewLayout: {
+    type: Object as PropType<(name?: string | boolean) => boolean>,
+    required: true,
+  },

---

151-163: Dynamic property-proxy incurs per-navigation defineProperty cost

Creating a fresh object and redefining every property on each navigation can add noticeable overhead when the route object contains many keys. Consider a lighter approach:

1. Use shallowReactive({ _: vueRouterRoute }) and expose a single computed getter, or
2. Cache the proxied object per layout instance and only swap the underlying source reference instead of re-defining descriptors.

Not urgent, but worthwhile for high-traffic apps.

test/nuxt/nuxt-layout.test.ts (1)

95-97: Avoid delete for performance – mutate instead

Static analysis flags delete layouts.test. Setting the entry to undefined (or calling router.removeRoute) sidesteps the hidden de-opt.

-  delete layouts.test
+  // eslint-disable-next-line @typescript-eslint/no-dynamic-delete
+  // layouts.test = undefined     // keeps object shape JIT-friendly
+  // or, if available:
+  // router.removeRoute('layout-slug')

🧰 Tools

🪛 Biome (1.9.4)

[error] 96-96: Avoid the delete operator which can impact performance.

Unsafe fix: Use an undefined assignment instead.

(lint/performance/noDelete)

test/bundle.test.ts (1)

120-120: Consider reducing brittleness of bundle size tests.

A strict inline snapshot for bundle size can lead to frequent test churn as the bundle evolves. You may want to use a tolerance or range-based assertion (for example, expect(bytes).toBeLessThanOrEqual(300 * 1024)) to make this test more resilient.

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

packages/nuxt/src/app/components/nuxt-layout.ts (2)

59-59: Non-null assertions are used safely but consider refining type safety

The non-null assertions (!) are used in a context where the code logic ensures the route is defined, making them safe. However, it might be better to use type guards or default values to avoid the need for assertions.

-let layout = unref(props.name) ?? route!.meta.layout as string ?? 'default'
+let layout = unref(props.name) ?? (route?.meta.layout as string) ?? 'default'

-const transitionProps = route!.meta.layoutTransition ?? defaultLayoutTransition
+const transitionProps = route?.meta.layoutTransition ?? defaultLayoutTransition

Also applies to: 88-88

---

145-165: Excellent route proxy implementation for handling fresh routes

The proxy implementation is very well done. It:

1. Checks if the component is outside of <NuxtPage>
2. Creates a dynamic proxy for the route that selectively uses either:
   • The eager route when rendering a new layout (ensuring fresh data)
   • The lazy route otherwise (maintaining compatibility with existing behavior)
3. Makes the proxy reactive with shallowReactive

This addresses the core issue of the PR by ensuring layouts always use fresh route data on first render.

However, I suggest adding a brief comment explaining why shallowReactive is used instead of reactive. The shallow version will only track changes to the top-level properties of the route, which is sufficient for this use case and more performant.

-      provide(PageRouteSymbol, shallowReactive(reactiveChildRoute))
+      // Using shallowReactive as we only need to track top-level route properties
+      provide(PageRouteSymbol, shallowReactive(reactiveChildRoute))

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro