Unnatural combination results

[TomokiMiyauci]

Several patterns resulted in results that differed from predictions. Are these intended results?

1. "https://example.test/" , "" -> "https://example.test"
2. "https://example.test/" , "/" -> "https://example.test"
3. "https://example.test//", "//" -> "https://example.test///"

Expected

1. "https://example.test/" "https://example.test/" -> "https://example.test/", so it is unnatural for the trailing slash to disappear.
2. "https://example.test/" Same as 1.
3. "https://example.test//" 　For an empty segment, the number of slashes appears to be -1.

from v2.0.4

[balazsbotond]

@TomokiMiyauci thank you for the feedback. I've tested this with the latest version (v3.0.0) with the following result:

"https://example.test/" + "" = "https://example.test/" "https://example.test/" + "/" = "https://example.test" "https://example.test//" + "//" = "https://example.test///"

This is very surprising and inconsistent. I'll look into it.

[balazsbotond]

This is actually documented in the README:

NOTE about empty path segments: RFC 3986 allows empty path segments in URLs (for example, https://example.com//users////2). urlcat keeps any empty path segments that aren't at the concatenation boundary between baseUrl and pathTemplate. To include an empty path segment there are two options:

• use a double slash: urlcat('https://example.com/', '//users', { q: 1 }) → https://example.com//users?q=1
• use the baseTemplate overload: urlcat('https://example.com//users', { q: 1 }) → https://example.com//users?q=1

This is admittedly not very clear but it basically means that if a duplicate slash would appear at the concatenation boundary, it will be automatically removed. So this is by design, even though a bit surprising.