Future-proof prepare argument

[benmccann]

It seems quite possible to me that you might want to use the host, method, path, query, etc.

[Conduitry]

We'd want to make sure it was clear somewhere that this is not the IncomingMessage object that you may be familiar with from Node. Is Kit's cross-provider 'request' object documented anywhere besides in its types?

[benmccann]

I'm not sure where the best place to mention that would be. Presumably it would be at least as relevant to mention elsewhere

[Rich-Harris]

Before adding this, can we figure out what the concrete use cases are? The main purpose of prepare originally was that it enables sessions, for which you only need headers. We should be careful not to add stuff 'just in case' it's useful.

Perhaps in the meantime we could change the signature from

(headers) => ({ headers, context })

to

({ headers }) => ({ headers, context })

so that it's future-proof and we can make this change one day in a non-breaking way?

[Conduitry]

I think this came out of a discussion in Discord that came out of Ben's call with the Apple guy. Part of the Discord conversation happened in voice chat, so I can't review all of it. I can't tell whether there's currently a concrete use case other than "Apple, for the unusual way that they pass data to pages that need it".

I'd definitely be in favor of making this an object instead, so that we can potentially expand it later. And we should probably also sweep for the API for other similar places where we are potentially hurting our ability to expand functionality in a backward-compatible way.

[benmccann]

The Apple use case was partially the motivation. I'm not necessarily sure this is the best way to solve their problem, but it might open a path for them even if suboptimal. My larger concern was probably about backwards compatibility as y'all mentioned here. I agree it's better to pass { headers } than headers. I thought { ...request } would be even better since it's equivalent and more powerful, but if the desire is to minimize the API surface instead I can get on board with that even if it wouldn't be my first inclination

[Rich-Harris]

nice, i like this — mind running pnpx changeset for the auto-releases?