Ky v2

[sindresorhus]

Some ideas for breaking changes:

• Hooks have very different parameters. Would be nice to unify that all of them accept a single state object. This makes it easier to add more properties in the future and makes it consistent.
• Allow beforeRequest hooks to proceed after updating request #387
• Remove some options from the normalized options passed to hooks. Like json. The types already do this, but the JS code was not in sync with the types.

[sholladay]

Thoughts on using object spread to implement .extend() instead of defaulting to deepMerge?

We could still provide the functionality by moving it into a separate helper function.

The benefit is that users can define their own semantics for how options are managed between instances.

See: #408

[kadhirr]

I think a welcome addition would be hooks to monitor failure of requests at network level. If that is on the cards would love to help out with that

[sholladay]

This thread is about breaking changes to the API, as in backwards incompatible, semver major changes.

We can add new hooks in v1, no need to wait for v2 for that.

[purepear]

Hey, thank you for your incredible work! 🙇
Wanted to share few ideas/struggles I had along the way in hopes that maybe some of it lands in v2.

Not necessary breaking changes but could be (depends on implementation I guess)

• Add an init hook #431 ideally async init hook
• Add baseUrl option, rename prefix, and allow leading slashes in input #606 baseUrl

My use case for init hook is to call an async function and modify the options (including headers, searchParams, baseUrl 🤞, etc) without deconstructing & returning new Request (which also limits me to 1 hook execution). At the time of raising the feature request I was looking to contribute but IIRC ky parses the options and creates the request in a class constructor so async init hook didn't seem easy to add.

Since then I checked out few other similar libraries and the ones using function (instead of class) usually support async hooks/middleware before request. The other way around is maybe creating the Request down the chain (outside the constructor) but that would also be quite the rewrite.

[sholladay]

Thanks for the suggestions, @purepear. Adding a new hook isn't breaking. I'm not sure whether we can make it async - as you mentioned that's complicated by the use of a class. But maybe we can find a way to make it work.

When I have time, I'm going to add an alias for the prefix option for backwards compatibility and then that baseUrl PR won't be breaking, either. We could consider getting rid of the alias for v2, though.