feat: add reply.getCookie and reply.getCookies methods

[lx3133584]

Problem

When cookies are set on the reply via reply.setCookie, there was no method to inspect or read the pending response cookies inside the route handler or early lifecycle hooks.

Root Cause

Pending cookies are accumulated in an internal reply[kReplySetCookies] map until the onSend hook writes them to the Set-Cookie header. FastifyReply lacked getter methods to query this map.

Fix

• Added fastifyCookieGetCookie and fastifyCookieGetCookies helpers.
• Decorated FastifyReply with reply.getCookie(name) and reply.getCookies().
• Added TypeScript definitions for the new reply methods in types/index.d.ts and types/index.tst.ts.

Testing

• Added unit tests in test/cookie.test.js asserting reply.getCookie and reply.getCookies return correct values before onSend.
• Verified 100% test coverage and TypeScript type tests pass.

[Copilot]

Pull request overview

Adds reply APIs for inspecting pending response cookies before onSend.

Changes:

• Adds reply.getCookie() and reply.getCookies().
• Adds TypeScript declarations and type assertions.
• Tests basic retrieval of pending cookies.

Reviewed changes

Copilot reviewed 3 out of 4 changed files in this pull request and generated 1 comment.

File	Description
index.js	Implements and decorates cookie getters.
test/cookie.test.js	Tests basic getter behavior.
types/index.d.ts	Declares the new APIs.
types/index.tst.ts	Verifies inferred return types.

Suppressed comments (1)

index.js:87

• A valid cookie name such as __proto__ invokes the inherited prototype setter here instead of creating an own property. The cookie is then absent from Object.keys()/normal lookup semantics, and the returned object's prototype is unexpectedly replaced. Define the property explicitly (or otherwise use a prototype-safe container).

    result[c.name] = Object.assign({ value: c.value }, c.opts)

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.