Add std/url with URL utilities

[ry]

Should have similar functionality to path: parent, basename, ext

but operate on JS native URL objects

[lino-levan]

Good to know that my analysis was not completely off-base 😅

[tr1ckydev]

<URL>.toString() allows itself to be used in std/path.

index.ts

import { parse } from "https://deno.land/std/path/mod.ts";

const url = new URL("https://deno.land/std@0.197.0/console/mod.ts");

console.log(parse(url.toString()));

console output

$ deno run index.ts
{
  root: "",
  dir: "https://deno.land/std@0.197.0/console",
  base: "mod.ts",
  ext: ".ts",
  name: "mod"
}

[kt3k]

@tr1ckydev If the platform is windows, std/path doesn't work for urls.

import { join } from "https://deno.land/std/path/win32.ts";
const url = new URL("https://deno.land/std@0.197.0/console/mod.ts");
console.log(join(url.toString(), "foo")); // => https:\deno.land\std@0.197.0\console\mod.ts\foo

[tr1ckydev]

Ahh, I see. Is std/url being currently worked upon or I can work on it and send a pr? ( I have already started working on it)

[kt3k]

I don't think anybody started working on it. Which APIs are you planning to implement? Could you share the API designs first?

[tr1ckydev]

I have tried to keep the API design similar to std/path with only difference being the input for the functions are string | URL and functions will always return as an instance of URL object wherever possible.
Currently I have implemented basename, dirname, extname, join, normalize, parse, format, sep.
Only relative and resolve is pending.

[tr1ckydev]

relative has been implemented but I am skeptical if resolve should be implemented in case of urls?

Also, I have started writing the tests for the functions, and they are working very promising so far.

[lino-levan]

You should be able to copy most if not all of the code from the posixX family of std/path. I would make sure to test edgecases though. Does implementing sep make any sense for URLs? What about format?

IMO, the only useful utilities would be xname, resolve, and maybe normalize. I'm not sure about parse. I think we should definitely NOT implement relative as we should be encouraging people to use the base URL class:

const url = new URL("../fr", "https://test.com/en-us")

As for join, as far as I can tell, the only difference between join and resolve is whether the path has to be absolute or not. For URLs, the path has to be absolute, so I would recommend either changing the behavior of join to resolve (to keep the name) or potentially just not including join at all in favor of resolve.

[tr1ckydev]

You should be able to copy most if not all of the code from the posixX family of std/path. I would make sure to test edgecases though.

Yes, I am using posix functions from std/path.

Does implementing sep make any sense for URLs?

Here's something to say. I have implemented sep as a function that can break https://github.com/denoland/deno_std to [ "https://github.com", "denoland", "deno_std" ] and SEP is a const of value "/"

What about format?

format just takes Partial<ParsedPath> as input and joins them.
parse parses the url into ParsedPath.

I think we should definitely NOT implement relative as we should be encouraging people to use the base URL class:

Agreed.

so I would recommend either changing the behavior of join to resolve (to keep the name) or potentially just not including join at all in favor of resolve.

How about resolve being an alias for join or vice-versa?

[lino-levan]

Here's something to say. I have implemented sep as a function that can break https://github.com/denoland/deno_std to [ "https://github.com", "denoland", "deno_std" ] and SEP is a const of value "/"

Is there a usecase for this? I feel like we should be pretty conservative about what we include in std.

format just takes Partial as input and joins them.
parse parses the url into ParsedPath.

Again, see above.

How about resolve being an alias for join or vice-versa?

Pretty strongly against this. I think resolve is unclear enough already. I think join should be fine.

[tr1ckydev]

Is there a usecase for this? I feel like we should be pretty conservative about what we include in std.

Okay, I get it. Then they can be omitted.

Pretty strongly against this. I think resolve is unclear enough already. I think join should be fine.

Sounds great. I will be keeping join only then.

[jollytoad]

I really like the idea of this module, as I often use the posix path fns for this, but having these use the existing path modules (v0.198.0) introduces unnecessary overhead from the windows implementations.

I've proposed a modification of the path modules structure that could alleviate this... https://github.com/denoland/deno_std/discussions/3553