Stupid (and objectively wrong) restriction

[patrik-simunic-cz]

Hello, firstly let me say, this library looks amazing. I was looking for a maintained and lightweight alternative to Axios when I came across ky and this library blew my mind. Simple, powerful and most of all, really lightweight. Kudos!

This being said, it just all the more breaks my heart that this library is completely unusable and I won't be using it on any project, probably ever. All for a tiny and seemingly stupid reason that you can't use a slash in the beginning of an input if you have a prefixUrl set. This is simply a big no-no, rationally, objectively.

I won't go into a detailed analysis, I think the mistake (with big M) has been largely covered here by @Spomky and @aintHuman: #70
But in short, you've basically created a huge deal-breaker (evidently for more people than just me) to solve an absolute non-issue (which a library like this shouldn't even remotely care about) and hence made this library and all the amazing work that went into it totally worthless. You're introducing an opinion, where none should exist. You're introducing a feature, which should not exist. If you need to request a path on the same host you don't set prefixUrl in the first place (like every other library like this does) - the feature to request a path on the samo host even if prefixUrl is set is just purely unnecessary and BS reason to introduce such restriction.

@sholladay said in that issue that he considered adding a second option (baseUrl) next to prefixUrl, that went nowhere. Do I really understand it correctly that because it „would be confusing to have both options“, you've decided to implement only the objectively wrong way, instead of at least giving developers the choice between objectively right and objectively wrong way? Rly??

But well, what can you do. I don't have the time to fork and FIX THIS ERROR, so good ol' fetch it is. It not as pretty as a lightweight library with fancy API, but still better to write a custom wrapper around fetch than to sacrifice decades old convention that exists for objectively sane reasons. Really breaks my heart... 💔

[nickchomey]

@patrik-simunic-cz Thanks for bringing this up here. I was just start to look at using ky, but might have to reconsider now.

Are you familiar with ofetch and wretch? They seem like good fetch-based candidates.

[suhaotian]

Maybe you want try xior.js too :)

[Spomky]

I decided to just use fetch. I don't have any dependency on project managers or restriction issues anymore.
fetch is simply the best candidate and is often overlooked in favor of unnecessary dependencies.

[nickchomey]

Thanks. That's beyond my capabilities, so I'll be using a package

[Spomky]

You mean writing something as follows is not easy?

const response = await fetch('https://example.com/books', {
	method: 'POST',
	body: JSON.stringify({author: "John Doe", title: "Foo Bar"}),
	headers: {
		'content-type': 'application/json'
	}
});

[nickchomey]

Ky does a lot more than a basic fetch... If that's all you needed from ky, then you wouldn't be here...

[Spomky]

Yes indeed, that's exactly why I came here 5 or 6 years ago.
But since then I've revised my mind (mainly due to the endless discussion pointed out by @patrik-simunic-cz) and have come to the conclusion that this 8k library is simply useless for my cases of use. fetch is sufficient for over 90% of my needs and this library, like all the others, is not required for such trivial features.

[sholladay]

I plan to fix this situation but It may be a while until I can get around to it.

The plan is roughly:

1. Make a PR that replaces prefixUrl with baseUrl (i.e. not have both) in order to avoid the confusion that Sindre is concerned about.
2. Document that when using baseUrl, a leading slash in the input URL is meaningful and can drastically change the final request URL. Recommend avoiding a leading slash in order to respect the full baseUrl, but allow it for those who need it.
3. (Maybe) Add a baseUrlMode option for people who want a leading slash in the input URL to not be meaningful, e.g. for a custom API client where the final request URL must always have /api even if the input URL has a leading slash. The option will default to 'resolve', but can be set to 'prefix' to opt-in to the current, legacy behavior, if you want/need to. In prefix mode, we may or may not do the leading slash validation, but we obviously won't in resolve mode.

I believe this will satisfy everyone. The API will have the flexibility that is needed for both use cases while still being simple via reasonable defaults. There will be no confusingly similar option names. Overall only one new option is actually added to the API. And Ky will no longer need to validate your input in an overly opinionated way unless, maybe, you opt into it.

In the meantime, cooperate on workarounds. We know there's demand for improvement. Calling all of the work that went into Ky "worthless" doesn't help and only demotivates open source contribution, which is all based on volunteer work. A dented Lamborghini is still a Lamborghini. People are building awesome things with Ky every day despite its flaws.