🦋 Changeset detected

Latest commit: 98c8565

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

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

@copilot not sure if you'll see this in time but it looks like you're adding options to cookies.get which is incorrect. I'm just going to quote myself from the original PR:

Thank you. This isn't quite right though — it only affects cookies that were created during the current request; the options are ignored for existing cookies. This leads to chaotic outcomes. Consider a case like this:

// src/routes/+layout.server.ts
export function load({ cookies }) {
  cookies.set('foo', 'bar', {
    path: '/'
  });
}

// src/routes/x/y/z/+page.server.ts
export function load({ cookies }) {
  return {
    foo: cookies.get('foo')
  };
}

When you visit /x/y/z for the first time, the cookies.set happens first followed by the cookies.get, which because of the defaults is equivalent to this...

cookies.get('foo', { path: '/x/y/z' });

...which returns undefined, incorrectly. When you reload the page, cookies.get instead reads from the cookie header.

My understanding (double-check me on this) is that the most specific cookie wins, which is to say that if you set all these (order doesn't matter)...

n=1; Path=/; HttpOnly; SameSite=Lax
n=2; Path=/x; HttpOnly; SameSite=Lax
n=3; Path=/x/y; HttpOnly; SameSite=Lax
n=4 Path=/x/y/z; HttpOnly; SameSite=Lax

...then on /x/y/z the Cookie header will be x=4; x=3; x=2; x=1 (which means cookies.get('x') === '4'), while on /x/y it will be x=3; x=2; x=1 (therefore 3) and so on.

So this PR is correct to ensure that cookies.set(name, ...) doesn't clobber existing name cookies, but the cookies.get logic isn't quite right. cookies.get(name) should not take an additional option, but it should look at all the matching cookies in new_cookies and select the most specific value.

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

@copilot not sure if you'll see this in time but it looks like you're adding options to cookies.get which is incorrect. I'm just going to quote myself from the original PR:

Thank you. This isn'...

You're absolutely right - adding options to cookies.get() was the wrong approach and led to inconsistent behavior. I've fixed this by:

1. Removing the domain and path options from cookies.get()
2. Implementing "most specific path wins" logic that searches all matching cookies in new_cookies and selects the one with the highest path specificity
3. Keeping the unique key storage system to prevent cookie overwrites during set()

The solution now correctly handles the scenario you described - cookies.get('foo') will consistently find the most specific matching cookie whether it's from a fresh set() call or from existing request headers. Commit c62add6

@copilot one of the tests you added is failing. Are you able to see the logs? On my phone right now but can help debug later

@copilot one of the tests you added is failing. Are you able to see the logs? On my phone right now but can help debug later

Fixed the failing test - the issue was in the path specificity calculation. Previously used .split('/').length which incorrectly gave the same score to '/' and '/foo' paths. Now using path length for accurate specificity comparison. Commit 12df174