[chore] separate RequestHeaders and ResponseHeaders types

[benmccann]

There doesn't seem to be a way to tell TypeScript that only set-cookie can be a string[], so just say that all header values can be string | string[] and deal with doing type assertions internally so that we can make things nice for our users

[changeset-bot]

🦋 Changeset detected

Latest commit: 3c57c7c

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

[ignatiusmb]

I know we've discussed this on discord, but man it feels really wrong to type cast everywhere, almost as wrong as using any in TS.

I'm still hoping there's another way around this, how did other frameworks handle this, and how did we get this far with having 'set-cookie' as the only one that can be an array? Can we somehow force it to just be string even more multiple cookies? Can we somehow provide a constrained identity function to work around this?

Edit:

how did we get this far with having 'set-cookie' as the only one that can be an array?

I meant this as "how is there no general Headers type available yet, that isn't a constructor or Map"

[benmccann]

Ok, I added a function to get the header rather than using the type cast

[ignatiusmb]

I'm really conflicted on this one, I hope it's okay if I call in another pair of eyes again 😅 @dummdidumm

Also, I haven't tried this so it might not work, but since we never (or rarely) use the string[] value from headers, we can probably get away with keeping them as string internally, but have them exported publicly as string | string[], so it'll only be loose when used outside of development, importing from @sveltejs/kit.

[dummdidumm]

I'm in favor, too. It's pragmatic, and we could change it some time in v2 if TypeScript is then able to type this.
How to handle this internally: I don't know where the public points are where users can use this, but the idea of having a transformation in one place and use string internally sounds nice and a little bit better than the current approach of always using the method. So my approval is more about the external change, and if the internal code can be refactored a bit to make the typings easier that would be great.

[ignatiusmb]

Alright, sounds good! It may take a while (or never if it isn't possible), but I'll try to think of a way we can achieve having only string internally