Option to treat empty parts in string input to default to wildcards

[crowlKats]

There should be an option to treat unspecified parts as wildcard instead of an empty string. For example, the current behaviour:

> new URLPattern("https://example.com")
URLPattern {
  protocol: "https",
  username: "",
  password: "",
  hostname: "example.com",
  port: "",
  pathname: "/",
  search: "",
  hash: ""
}

what i would like:

> new URLPattern("https://example.com", { defaultToWindcard: true })
URLPattern {
  protocol: "https",
  username: "*",
  password: "*",
  hostname: "example.com",
  port: "*",
  pathname: "/",
  search: "*",
  hash: "*"
}

The one problem I see however is the fact that pathname still would default to "/"

[wanderview]

You can write new URLPattern({ protocol: 'https', hostname: 'example.com' }) if you want this behavior. This unambiguously leaves URL components undefined which are defaulted to wildcards.

When you specify a full URL like new URLPattern('https://example.com') the URL parser does not leave any undefined components. Everything is precisely defined. It seems dangerous for the URLPattern to decide that some values are actually wildcards and others not. While the opt-in limits this risk, its not clear its any better than the alternative above.

Do you have example use cases that won't work with the other form?

[crowlKats]

The usecase is user-provided input. I had the usecase for this a few months back, but cannot remember what I needed it for anymore, however my usecase now would be that I want to change Deno's network permission flag to accept a pattern (instead of currently only accepting hostname & port), to allow more fine-grained control. In Deno, permissions are passed via CLI flags, so using the object to set fields isnt viable, but if a user wants to give full permissions to a specific domain (which is the most common case), they would have to pass something like *://*:*@example.com:*/*?*#*, which would be terrible UX.

I guess the alternative would be parsing twice: once with the string provided, and a second time with the fields of the URLPattern, and replacing any empty strings with wildcards, though seems not ideal.

[wanderview]

Right, you can use new URL() on the user input and then populate a js object with its fields. If you just strip empty fields then passing the object to new URLPattern() does the thing you want.

[crowlKats]

@wanderview that doesnt work; ie an input of *://example.com will throw on new URL()

[wanderview]

Ah, you are correct. So you do have to use two URLPattern objects, but the second one can use the decomposed constructor form which avoids some parsing.

[crowlKats]

Yea, i think thats the way forward. not a fan of having to parse twice, but can see little need for this and being part of the spec seems unecessary, so will close this issue