packages/nuxt/src/app/composables/cookie.ts (2)

82-90:refresh currently bypasses thereadonly guard in the client callback

On the client,callback and the watcher now behave as:

constcallback=(force=false)=>{if(!force){if(opts.readonly||isEqual(cookie.value,cookies[name])){return}}writeClientCookie(...)…}if(opts.watch){watch(cookie,()=>{if(watchPaused){return}callback(opts.refresh)},{deep:opts.watch!=='shallow'})}

Whenrefresh: true, the watcher always callscallback(true), which skips theopts.readonly branch and allows writes even for cookies declared asreadonly. Whilereadonly is mostly a TypeScript‑level contract, it is still surprising that enablingrefresh changes the runtime behaviour from “never write” to “may write”.

If you wantreadonly to remain a hard guarantee, you could separate the two concerns:

-    const callback = (force = false) => {-      if (!force) {-        if (opts.readonly || isEqual(cookie.value, cookies[name])) { return }-      }+    const callback = (force = false) => {+      if (opts.readonly) { return }+      if (!force && isEqual(cookie.value, cookies[name])) { return }       writeClientCookie(name, cookie.value, opts as CookieSerializeOptions)       …     }    if (opts.watch) {      watch(cookie, () => {        if (watchPaused) { return }-        callback(opts.refresh)+        callback(opts.refresh)      }, { deep: opts.watch !== 'shallow' })    }

This preserves the “force refresh even when the value is unchanged” behaviour while ensuringreadonly cookies are never written from the client.

Also applies to: 134-140

---

92-99:BroadcastChannelrefresh handling is coherent, but consider the source tab’s behaviour

The newhandleChange signature:

consthandleChange=(data:{value?:any,refresh?:boolean})=>{constvalue=data.refresh ?readRawCookies(opts)?.[name] :opts.decode(data.value)…}

allows tabs that receive{ refresh: true } (viarefreshCookie) to reread the cookie fromdocument.cookie, which is sensible: they do not rely on another tab’s encoded payload and instead use their own view of the cookie jar.

One nuance worth double‑checking is thatrefreshCookie(name) on the current tab only posts a message; it doesnot itself call the localcallback that writes the cookie again with a freshmaxAge. That means:

• The tab that callsrefreshCookie does not extend the cookie’s expiry by itself.
• Only tabs that have auseCookie watcher and receive the broadcast will update their local ref to whatever is already indocument.cookie.

If the intent is thatrefreshCookie should actively extend the cookie TTL in the caller as well, you may want to either call the same write path locally, or document thatrefreshCookie is purely a cross‑tab synchronisation helper and relies on some other code path to perform the actual refresh.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

docs/4.api/2.composables/use-cookie.md (1)

64-64:Markdown table alignment issue (duplicate of previous review).

The MD060 markdownlint error regarding pipe alignment on this line was previously flagged. Ensure the table pipes are consistently aligned with the heading row. Runmarkdownlint ./docs --fix to auto-correct the alignment.

docs/4.api/2.composables/use-cookie.md (1)

168-188:Example could better demonstrate the intended use case.

The example shows a single assignment in<script setup>, which doesn't fully illustrate the intended use case of refreshing cookie expiration on repeated activity. Consider enhancing the example to show multiple assignments (e.g., triggered by user interactions) to clarify when and whyrefresh: true is beneficial.

For instance, the example could demonstrate assigning the same value in response to user activity (like button clicks) to extend the session expiration, which is the primary motivation for this feature.

Would you like me to suggest an enhanced version of this example that better demonstrates the activity-based refresh pattern?

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro