feat(path/unstable): support URL input in dirname()

[kt3k]

part of #5537

This PR adds dirname(url: URL): string overload to dirname function.

If a user have a file URL string or object, currently they need to convert it to a path string first to perform path operation on it:

import { dirname, fromFileUrl } from "@std/path";

dirname(fromFileUrl(new URL(import.meta.url)));

This change makes it simpler by automatically interpret the file URL as path

import { dirname } from "@std/path";

dirname(new URL(import.meta.url));

[codecov]

Codecov Report

Attention: Patch coverage is 92.30769% with 1 line in your changes missing coverage. Please review.

Project coverage is 96.27%. Comparing base (99200dc) to head (11813f9).
Report is 4 commits behind head on main.

Files	Patch %	Lines
path/dirname.ts	66.66%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #5747      +/-   ##
==========================================
- Coverage   96.28%   96.27%   -0.01%     
==========================================
  Files         474      474              
  Lines       38383    38391       +8     
  Branches     5578     5584       +6     
==========================================
+ Hits        36957    36962       +5     
- Misses       1384     1387       +3     
  Partials       42       42              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[iuioiua]

LGTM once assertThrows() comments are addressed.

This PR does make me think; what if someone does want to get the parent path of a HTTP URL? E.g. I want to get /documents from https://example.com/documents/image.png. How do I do that? Is that regarded as the directory in a HTTP URL? I think it's a valid use case and we should cater to it.

[kt3k]

pathname part of URL object is usually a posix path. I think we can recommend using posix.dirname to it:

> posix.dirname(new URL("https://example.com/documents/image.png").pathname)
"/documents"

[iuioiua]

Sorry, I want to understand; is there a reason for only allowing dirname() to only work on file URLs?

pathname part of URL object is usually a posix path. I think we can recommend using posix.dirname to it:

> posix.dirname(new URL("https://example.com/documents/image.png").pathname)
"/documents"

I think your example should work without having to call .pathname.

[kt3k]

If we simply allow http urls, what happens with the call like posix.dirname(new URL("https://example.com"))?

[iuioiua]

We could throw, return null or return /.

[kt3k]

http URLs are not paths while file URLs are equivalent of paths. I think that kind of handling is out of scope of @std/path