suggestion: have url.dirname() return string instead of URL

[iuioiua]

It currently returns a URL instead of a string. I find this behavior surprising, as it requires the user to call .href in most cases. Do you have any thoughts, @marvinhagemeister?

[marvinhagemeister]

Doesn't it already return strings https://jsr.io/@std/url/doc/~/basename ?

[iuioiua]

(sighs) I meant dirname() 😅

[kt3k]

APIs in url consistently return URL instance when the returned value can be expressed as URL (dirname, join, normalize). extname and basename return string as the returned values can't be expressed as URLs

[iuioiua]

It makes sense for join() (join URLs) and normalize() (normalize a URL) to return URLs. I'd expect dirname() to behave the same way basename() and extname(), as their names imply.

[marvinhagemeister]

Both points of views make sense to me and are valid options. So it comes more down to what we expect developers to use it for. I'm trying to make a case from that perspective. In apps I've written the dirname() function on paths is typically used to traverse upwards, like finding the nearest deno.json for example. A similar use case seems to apply to URLs as well. If the type changes to a string you'd constantly have to cast it back to a URL again. For that reason it seems to make more sense to me that dirname() returns a URL instance. You can always get back the stringified variant by doing url.pathname I guess.

[iuioiua]

Alright. I'm unsure I fully agree, but let's leave it as-is.

[kt3k]

There was also a small discussion about dirname when it was first landed #3527 (comment)