refactor: use cookie-es for cookie utils

[pi0]

I noticed that svelte-kit depends on multiple cookie packages cookie, set-cookie-parser, @types/cookie + workarounds for CJS support.

unjs/cookie-es packs cookie and set-cookie-parser functionality as an ESM-only and typed package (used and tested across UnJS and Nuxt ecosystem).

This PR reduces install size (cookie:45.4/cookie types: 47.1/set-cookie:15.7) 108kB to 20.2kB

Also opened discussion: #13511

---

Totally unrelavant question: Have you considered trying autofix.ci to auto fix format issues? It is amazing!

---

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

• It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
• This message body should clearly illustrate what problems it solves.
• Ideally, include a test that fails without this PR but passes with it.

Tests

• Run the tests with pnpm test and lint the project with pnpm lint and pnpm check

Changesets

• If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpm changeset and following the prompts. Changesets that add features should be minor and those that fix bugs should be patch. Please prefix changeset messages with feat:, fix:, or chore:.

Edits

• Please ensure that 'Allow edits from maintainers' is checked. PRs without this option may be closed.

[changeset-bot]

🦋 Changeset detected

Latest commit: 4fb5630

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@sveltejs/kit	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[svelte-docs-bot]

Preview: https://svelte-dev-git-preview-kit-13512-svelte.vercel.app/

[dummdidumm]

Nice to know, thank you! Since this likely depends on the newest cookie version which has a breaking change we can only do this in 3.0

[pi0]

Since this likely depends on the newest cookie version which has a breaking change we can only do this in 3.0

Actually, I haven't migrated cookie-es to be like latest upstream major yet (for same concerns of breaking changes). It will happen for cookie-es v3 likely (if we do)

[dummdidumm]

Oh interesting! Any time frame on that (you said "if we do" which sounds like you might not do for a long time?)

[pi0]

I mean unless find a way to reduce/avoid breaking changes surface in cookie-ea during next sync.

I don’t have any time frames for next major, but we can discuss it later if you like general idea of this migration.

[benmccann]

This might be a nice way to eliminate the security warning associated with the cookie library in the short-term. It's kind of papering over it, but it'd be a breaking change for us to upgrade the cookie library (#13386) so it might be the best option we have in the immediate future

Just to clarify, we don't care about CJS at all. SvelteKit has been ESM-only since day 1

Combining both pieces of functionality into a single package is nice. It looks like the cookie library is considering that as well: jshttp/cookie#200

[teemingc]

We should probably update the Netlify adapter to use the cookie-es package too
https://github.com/sveltejs/kit/blob/main/packages/adapter-netlify/src/headers.js

[manuel3108]

This recently came up in the cli repo as well: sveltejs/cli#512

Instead of adding a package.json override in the sv create templates, I think we should solve the core problem as discussed here. Would love to see this move forward.

[Conduitry]

To summarize what I said in the maintainers channel - I don't think switching libraries is a good solution. My understanding is that this has the same vulnerability as the existing library - it just never received a CVE for it. So switching libraries solely for the sake of hiding a security warning isn't the right way forward. Once cookie-es ports the fixes/tightening done in later versions of cookie, we can reconsider switching - but I'd still want to weigh what we're really getting out of switching to a much less popular library.

[benmccann]

While I'm modestly in favor of this PR, I think the overall sentiment in the maintainers group was a preference for sticking with the more widely used upstream library. I think we'll get to SvelteKit 3 before too long and upgrade that library to the latest version, which will at least fix the security warning you get when using it