Repository navigation
url.relative (to complement path.relative) #616
Description
The core url module currently has url.resolve() to compute absolute URLs from relative segments (which is complementary with path.resolve()). but it is missing the complementary .relative() function to compute relative URLs from two absolute URLs.
Many programs simply use path.relative() when dealing with URLs (e.g.: https://github.com/substack/node-browserify/blob/ce3deecf7be27373c0131286bda86533ec83ffd1/index.js#L692 ) but on Windows systems, path.relative() uses the path.sep character, resulting in relative URLs like ..\\..\\a\\b instead of ../../a/b.
The algorithm for computing relative URLs is (AFAIK) the same, but the separator character should always be a / as specified in RFC 3986 Section 3.3.
Opening this for discussion here prior to writing a PR.
Activity
Qard commentedon Jan 27, 2015
+1 from me. I see no reason not to have it.
rvagg commentedon Jan 27, 2015
Not exactly a great rule to guide additions to core. I guess this points to the need for clearer guiding principles; something like "minimalism and quality API" would sum it up for me.
Qard commentedon Jan 27, 2015
Well, I don't mean we should just accept anything that's not blatantly against the spirit of core. Minimalism is certainly good.
I just agree that the consistency with the path module is nice too, and it seems both generally useful and relatively easy to support.
Fishrock123 commentedon Jan 27, 2015
Seems like something that users would expect. ±0
junosuarez commentedon Jan 27, 2015
Agree with @rvagg that there should be a guiding principle, and I generally agree with "keep core small, push things into userland modules." In that spirit, I published url-relative.
Another principle to balance is "principle of least surprise" in terms of providing consistency across core apis. I knew about and use
path.relative()fairly often, and was surprised not to set an equivalent function for dealing with urls. Since theurlmodule is at stability 3, I figured this issue was worth raising.rvagg commentedon Jan 27, 2015
ftr I'm not a -1 on this, but I'm going to label it semver-minor so if this gets solid sponsorship from a collaborator and no -1s then it can be merged but we first need to figure out a good model for doing minor version bumps and handling that with git
Fishrock123 commentedon Mar 24, 2015
@jden maybe you could send a PR for it?
stevenvachon commentedon Apr 16, 2015
There's also relateurl which does its best to keep the url as short as possible, which is pretty well the only reason to use a relative url.
sam-github commentedon Jun 18, 2015
-1
core url library isn't the be-all of url manipulations, its not even spec conformant! See nodejs/node-convergence-archive#49 (EDIT: pointed to correct issue 49)
url has minimal set of url features required to implement node itself, I don't think we should add to it, leave it to user-land.
Fishrock123 commentedon Jun 24, 2015
Yeah, closing unless people decide it's a good idea for inclusion.
graingert commentedon Oct 20, 2016
@sam-github #49 links to something else due to the split to the archive. See nodejs/node-convergence-archive#49
felixfbecker commentedon Nov 13, 2018
Imo this is a very core thing - just like URL parsing itself - to have in core. If resolving absolute URLs from relative URLs is considered core, then why is resolving relative URLs not?
I've been using https://github.com/suarasaur/url-relative but it has some pretty serious bugs, like considering URLs with different protocols the same (e.g.
httpvshttps), as well as auth, or downright getting into an infinite loop when the inputs are the same. We should have a reliable solution in core.stevenvachon commentedon Nov 13, 2018
@felixfbecker that is an awful library. Try "relateurl".
felixfbecker commentedon Nov 13, 2018
@stevenvachon Thanks for the tip, that library definitely works better. However, it is clear that it was built for the use case in a minifier, and therefor has a lot of defaults I need to override to get pure relative URLs. For example, it removes default ports, removes trailing slashes, and returns absolute paths if the resulting URL is shorter. That seem like good choices for a minifier, but if I just want to create relative URLs for my application, and then for example mount the relative URL on top of a different URL with
url.resolve()this is very dangerous because the resulting URL will not always be equivalent.I still believe Node should have a low-level, unopinionated API for this in core.
stevenvachon commentedon Nov 29, 2018
@felixfbecker the WHATWG
URLstandard also removes default ports and this is the new parsing algorithm used in Node.js v11http. Therelateurllibrary has a "careful" profile for your use case.