test/cookies.test.ts (1)

145-152: Good targeted regression test; consider extending coverage to stringify.

The test correctly exercises the fix: with the previous behavior, encode would have been ignored and the default encoder would have re-escaped % to %25, so this would have failed. Nice.

Two optional nits:

• stringify is the other option extracted in setCookie but is not covered by any test. A small companion test (e.g. setCookie(event, "x", { foo: 1 } as any, { stringify: (v) => JSON.stringify(v) })) would lock in both halves of the fix.
• For consistency with the surrounding tests, you may want to also assert expect(await result.text()).toBe("200"); so the handler's return path is verified.

     it("respects custom encode option", async () => {
       t.app.get("/", (event) => {
         setCookie(event, "x", "%22true%22", { encode: (v) => v });
         return "200";
       });
       const result = await t.fetch("/");
       expect(result.headers.getSetCookie()).toEqual(["x=%22true%22; Path=/"]);
+      expect(await result.text()).toBe("200");
     });

🤖 Prompt for AI Agents

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

In `@test/cookies.test.ts` around lines 145 - 152, Add a companion test to cover
the `stringify` option in addition to `encode`: create a test (e.g., "respects
custom stringify option") that calls setCookie(event, "x", { foo: 1 } as any, {
stringify: (v) => JSON.stringify(v) }) in the request handler, fetch the route,
assert the Set-Cookie header contains the JSON stringified value, and also
assert the response body via expect(await result.text()).toBe("200");; update
the existing "respects custom encode option" test to include expect(await
result.text()).toBe("200"); so both handler return paths are verified.

src/utils/cookie.ts (1)

88-89: LGTM — clean fix for the encode/stringify pass-through.

Splitting encode/stringify out of the cookie attributes object and forwarding them as the dedicated SerializeOptions argument is the correct fix. The previous code path was effectively dropping these callbacks because cookie-es ignores them when present on the SetCookie attribute object.

Two small notes (non-blocking):

1. Line 99 just below still uses options || {} while the new line 88 uses options ?? {}. Consider aligning to ?? for consistency (treats only null/undefined as missing, which is the intent here since options is typed as CookieSerializeOptions | undefined).
2. As you already called out in the PR description, { name, value, path: "/", ...attrs } lets a caller-supplied name/value/path in options silently override the explicit args. Worth following up upstream in cookie-es as you suggested — not a regression in this PR.

🤖 Prompt for AI Agents

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

In `@src/utils/cookie.ts` around lines 88 - 89, The code correctly extracts
encode/stringify into serialize options, but two small fixes remain: (1)
normalize nullish handling by using the nullish coalescing operator for options
everywhere (replace uses of options || {} with options ?? {}) so only
null/undefined fall back; (2) prevent caller-supplied name/value/path in options
from silently overriding explicit args by excluding name, value, and path from
the spread attrs before building the cookie object passed to serializeCookie
(ensure { name, value, path: "/", ...attrsWithoutNameValuePath } is used),
keeping encode/stringify passed as the second argument to serializeCookie.