but I don't want to break compatibility

What kind of compatibility would it break? I would like to make it on by default. Just trying to think about the repercussions.

Thinking out loud, do we even need an option for this? It kinda feels like a bug-fix. The existing behavior is clearly incorrect.

It's correctly handled by new URL, for example:

new URL('custom+with+plusses://sindresorhus.com')
//=> URL {origin: "null", protocol: "custom+with+plusses:", username: "", password: "", host: "", …}

You're right, there probably aren't any compatibility changes, I'm always just a bit cautious when I'm adding a new use case and I'm not the author, so there may be things I've missed.

I'll make this the default behavior then 👍

Do you want to keep the error on the view-source protocol?

There's one possible ambiguity here. See: sindresorhus/prepend-http#4 Not sure how to handle that. Either disallow auth or require the custom protocol to use //. Thoughts?

I don't think this library handles auth in the url does it? Or at least currently it strips it out.

eg:

normalizeUrl('https://username:password@sindresorhus.com')
// -> 'https://sindresorhus.com'

This PR shouldn't affect that, since like you say, it uses // as the delimiter.

Edit: According to the spec, the delimiter between protocol (scheme) and other things should be : (here). I honestly can't understand the parts after that, but there's no obvious requirement for // following it, which is weird. That might just be my misunderstanding though. Shall we keep // as the delimiter and just mention that custom protocols need to use it?

I don't think this library handles auth in the url does it? Or at least currently it strips it out.

You're right. Then that's a non-issue.

Shall we keep // as the delimiter and just mention that custom protocols need to use it?

Not sure what you're asking, but we should preserve it if it's there. We cannot normalize it away as it changes the semantics.

Do you want to keep the error on the view-source protocol?

I think we could remove it.

Bump :)

Closing for lack of response. Happy to reopen if you ever get to this.

#152