Allow custom path for preview mode cookies

[lucasassisrosa]

Fixes #38312

Bug

• Related issues linked using fixes #number
• Integration tests added
• Errors have helpful link attached, see contributing.md

Feature

• Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR.
• Related issues linked using fixes #number
• Integration tests added
• Documentation added
• Telemetry added. In case of a feature if it's used or not.
• Errors have helpful link attached, see contributing.md

Documentation / Examples

• Make sure the linting passes by running pnpm lint
• The examples guidelines are followed from our contributing doc

[lucasassisrosa]

I was also considering doing something like

Suggested change

	...(options.path !== undefined
	? ({ path: options.path } as CookieSerializeOptions)
	: undefined),
	...(options.path !== undefined
	? ({ path: options.path || '/' } as CookieSerializeOptions)
	: undefined),

but I found out that there's a normalization function for the cookie serialize function params.

Also, I though about refactoring this maxAge and path props to have a single object like

Suggested change

	...(options.path !== undefined
	? ({ path: options.path } as CookieSerializeOptions)
	: undefined),
	...({ path: options.path , maxAge: options.maxAge }),

But when path or maxAge is empty, we'd be passing { path: undefined, maxAge: undefined } instead of { }. Those are actually different, and I'm not certain how the options object properties are treated down the chain

[lucasassisrosa]

While checking CookieSerializeOptions type definitions, I noticed that it'd be good to update it to v0.5.1 to get the latest (and more complete definitions). /@types/cookie/0.5.1 has correct links to https://datatracker.ietf.org/doc/html/rfc6265#section-5.2.4 which is way more helpful to understand how this path and maxAge behave. I thought about doing it in the same PR, but I think it's rather better to keep deps updates isolated

[lucasassisrosa]

I thought it'd be good enough to just accept raw path as string in this setPreviewData function here without extra parsing/validation on it because developers would control the setPreviewData call and its parameters, just like they do with redirects inside the preview API endpoint. The security concerns around path remain the same though - https://datatracker.ietf.org/doc/html/rfc6265#section-4.1.2.4

[ijjk]

Hi, being able to enable preview mode for specific paths sounds like a good addition, thanks for the PR!