Trying to make sense of break statement

[monojack]

Can anyone explain why there's a break statement here?

[sindresorhus]

Explained in the docs:

The hook can return a Request to replace the outgoing request, or return a Response to completely avoid making an HTTP request. [...] An important consideration when returning a request or response from this hook is that any remaining beforeRequest hooks will be skipped, so you may want to only return them from the last hook.

[monojack]

Thank you, I've read the docs, but it doesn't make sense to me. I guess it was a design decision at some point and I'm curious about why that was the choice. Is there a potential issue that could come up or just hand-holding? I'm genuinely curious about what could go wrong..

[sindresorhus]

I'm not sure to be honest. The feature was added here but there were no discussion around it: #172 If you think following hooks should not be skipped, open an issue and argue your case.

[monojack]

Oh, I see, although that's for when returning a Response, which makes sense. Support for returning a new Request was added here. Looks like that was just the initial implementation, although, I would argue it's not necessary. Anyway, thank you so much, you've been more than kind considering this has been there for 5 years already, but I've just recently tried Ky and bumped into this limitation, which is a blocker for me.

[sholladay]

Hi! I implemented the ability to return a Request from a hook as an escape hatch, in case people don't like something about the way we process and normalize the request options and create our internal Request instance. It allows you to bypass some of Ky's logic, which has been useful for working around bugs, among other things.

If I understand correctly, you're hoping to make use of this feature but without skipping the following beforeRequest hooks. Is that right? If so, I think that's definitely something we can consider. Can you show me your code and help me understand how you're planning to use it?

At the time, I just wanted to make the behavior consistent with what we already had (i.e. returning a value from a hook always has the same semantics). But I can see how you might want to have multiple beforeRequest hooks incrementally modify the Request or something. For now, maybe you could use some other mechanism to share state between your hooks and return the Request only in the last hook?

BTW, headers can be modified without returning a new Request by calling request.headers.set().