URL.canParse()

[hemanth]

It would be good to have a URL.isValid method?

Today we have to do something like:

const isValidUrl = (s) => {
    try {
      new URL(s);
      return true;
    } catch (err) {
      return false;
    }
};

The proposal is to have something like:

URL.isValid(<URL>, [protocol1, protocol2]);

URL.isValid('https://h3manth.com'); // true
URL.isValid('https://h3manth.com', ['file']); // false 

[jasnell]

"Valid" here will need to be defined as the spec defines a clear notion of a "validation error". Specifically, a URL can parse successfully but still be considered "invalid" per the spec. Does "isValid(...) === true" mean that the URL parses successfully or does it mean it parsed without any validation errors?

[jasnell]

As far as bikeshedding the API is concerned, I would likely prefer something more like:

URL.test(input[, base]);

With the semantics specifically only limited to: Will this parse successfully.

[domenic]

Please see https://whatwg.org/faq#adding-new-features, especially step 1 and 2.

[annevk]

With the semantics specifically only limited to: Will this parse successfully.

How would that be different from what new URL() does?

[jasnell]

How would that be different from what new URL() does?

The key difference would be no allocations, in particular no Error object created if it does not parse, and therefore no expensive stack capture.

[hemanth]

@domenic Should we provide more use-cases here? All that we are trying to solve here is to have a convenient way to identify if a given URL is valid or not.

@jasnell test reminds me of RegExp.prototype.test like testing against something, isValid sounds more intuitive?

Either way if we agree this is a problem space, happy to discuss more.

[annevk]

@hemanth well it would help if you would first clarify what semantics you are after as validity and "can parse" are very different things. (But yeah, depending on the answer, use cases and demonstrating there is a need would help.)

[jasnell]

The primary use case I've encountered for this is really functions like the isValid() in the OP at the top. Specifically, code that wishes to verify that a given input can be handled as a URL (can parse) without incurring the additional cost of creating either a URL object or an Error object with an expensive to generate stack. I've encountered this pattern a number of times.

Most often, I'd say, the check is performed using a regex, which is problematic in that it doesn't match the parsing semantics and can be difficult to make correct. There's an old module on npm called is-url that has over 2.5 million downloads per week to address this specific problem using an incomplete regex approach.

For me, I would 100% support an API that checks if an input can be parsed as a URL. I have no use case for further validity checks.

Alternatively, I would be good with a new URL constructor variation that did not throw on unparseable input so as to avoid the expensive operation to acquire the stack.

[hemanth]

@annevk My thoughts resonated completely with @jasnell. There is also valid-url another node module which is dependent on regex and got around 2,788,820 downloads last week.

This is a very common pattern across multiple code base and would be beneficial to multiple developers to have a connivence method with in the standards.

If there is a template repo that I can fork and add more structure to the challenge and propose potential solutions, I am happy to collaborate.

[annevk]

See also #372 although that would not return a boolean presumably.

Given that there's popular libraries that do something like this this is worth doing I think, but this is not validation. We should either call this something like canParse and return a boolean or parse and return null or a URL object.

[domenic]

It's not clear to me solving this at the level of a new API is the best idea. Wouldn't it be better to make try / catch faster? In particular, if you use catch { } instead of catch (e) { }, that should be a reliable signal to the engine that there's no need to construct a stack, which is apparently expensive (benchmarks pending).