docs/3.api/3.utils/define-page-meta.md (1)

117-121: ⚠️ Potential issue

Documentation text doesn't match the updated type definition

While the type in the interface has been updated to ViewTransitionPageOptions['enabled'] | ViewTransitionPageOptions, the documentation still describes it as boolean | 'always'. This could be confusing for users trying to implement the enhanced view transition options.

Apply this diff to update the documentation:

- **Type**: `boolean | 'always'`
+ **Type**: `boolean | 'always' | ViewTransitionPageOptions`

Add a brief explanation about the expanded capabilities:

If set to true, Nuxt will not apply the transition if the users browser matches `prefers-reduced-motion: reduce` (recommended). If set to `always`, Nuxt will always apply the transition. Alternatively, you can provide a `ViewTransitionPageOptions` object to specify transition types for more granular control.

🧰 Tools

🪛 LanguageTool

[uncategorized] ~121-~121: It looks like there might be a possessive apostrophe missing. Consider inserting it.
Context: ...xt will not apply the transition if the users browser matches `prefers-reduced-motion...

(AI_EN_LECTOR_MISSING_NOUN_POSSESSIVE)

packages/nuxt/src/app/plugins/view-transitions.client.ts (1)

67-78: Optional: remove @ts-expect-error by widening lib types instead

Using // @ts-expect-error hides legitimate typing mistakes. Consider type-augmenting document.startViewTransition instead, so the extra update/types properties are recognised:

declare global {
  interface Document {
    startViewTransition(init?: {
      update?: () => Promise<void>
      types?: string[]
    }): ViewTransition
  }
}

This keeps IntelliSense and build-time safety intact.

packages/schema/src/types/config.ts (2)

166-169: Naming convention might cause confusion.

The toTypes and fromTypes properties combined with the function signature (to, from) => [string] could be confusing. Consider adding a documentation comment clarifying that:

• toTypes specifies transition types when navigating to the page (with this configuration)
• fromTypes specifies transition types when navigating away from the page (with this configuration)

This would prevent misunderstanding when implementing these functions.

 export interface ViewTransitionPageOptions extends ViewTransitionOptions {
+  /**
+   * Specifies transition types applied when navigating TO this page.
+   * In the function signature, 'to' refers to the route being navigated to.
+   */
   toTypes?: [string] | ((to: RouteLocationNormalizedGeneric, from: RouteLocationNormalizedGeneric) => [string])
+  /**
+   * Specifies transition types applied when navigating FROM this page.
+   * In the function signature, 'from' refers to the route being navigated from.
+   */
   fromTypes?: [string] | ((to: RouteLocationNormalizedGeneric, from: RouteLocationNormalizedGeneric) => [string])
 }

---

161-164:

Details

❓ Verification inconclusive

Consider clarifying the types property definition.

The types property is defined as [string] (a tuple with exactly one string), which seems restrictive. If multiple transition types are supported, consider using string[] instead for flexibility.

---

🏁 Script executed:

#!/bin/bash
# Check how view transition types are used in the implementation
grep -r "types.*\[string\]" --include="*.ts" --include="*.vue" packages/
grep -r "startViewTransition.*types" --include="*.ts" --include="*.vue" packages/

Length of output: 304

---

Verify tuple vs. array for types in ViewTransitionOptions

The current definition in packages/schema/src/types/config.ts enforces a single-element tuple ([string]), which may be too restrictive if multiple transition types are supported. No references to this interface or its types field were found elsewhere in the codebase, so please confirm whether the tuple is intentional or should be widened to an array.

• File: packages/schema/src/types/config.ts (lines 161–164)

-export interface ViewTransitionOptions {
-  enabled: boolean | 'always'
-  types?: [string] | ((to: RouteLocationNormalizedGeneric, from: RouteLocationNormalizedGeneric) => [string])
-}
+export interface ViewTransitionOptions {
+  enabled: boolean | 'always'
+  types?: string[] | ((to: RouteLocationNormalizedGeneric, from: RouteLocationNormalizedGeneric) => string[])
+}

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

docs/3.guide/6.going-further/1.experimental-features.md (1)

324-326: Clarify the second read-more block to differentiate it from the first.

Both read-more blocks use identical text ("Read more about the View Transition API") but link to different resources. The first links to MDN's general API documentation, whilst the second links to Chrome's blog post specifically about view transition types. This could confuse readers who might skip the second link thinking it's a duplicate.

📝 Suggested text change

-::read-more{icon="i-simple-icons-google" to="https://developer.chrome.com/blog/view-transitions-update-io24" target="_blank"}
-Read more about the **View Transition API**.
-::
+::read-more{icon="i-simple-icons-google" to="https://developer.chrome.com/blog/view-transitions-update-io24" target="_blank"}
+Read more about **View Transition Types** in the Chrome update.
+::

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@docs/3.guide/6.going-further/1.experimental-features.md` around lines 324 -
326, The second ::read-more block currently duplicates the text "Read more about
the **View Transition API**" while pointing to a different URL; update its text
to clearly indicate the specific resource (for example "Read Chrome's blog post
on View Transition types") so readers know it links to the Chrome I/O article
rather than the general MDN doc, and keep the
::read-more{icon="i-simple-icons-google"
to="https://developer.chrome.com/blog/view-transitions-update-io24"
target="_blank"} attributes unchanged.

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro