-
Notifications
You must be signed in to change notification settings - Fork 29.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
url: re-add path in url.format #893
Conversation
node.js has rejected this patch because it could not decide what to do when the object contains both 'path' and 'pathname'. I don't think that iojs has answered that question, although the tests seem to contain some rules. |
my vote would be top prioritise |
@piscisaureus @chrisdickinson has merged the patch at nodejs/node-v0.x-archive#8755, and we have discussed how the Actually the most initial purpose of this patch is to keep Btw, this issue is not big deal to me, I just wanna let the url in our internal modules be neater, so if you guys think it breaks too much, feel free to close it. |
Ok, the discussion in node seems to have been thorough enough so I move io accepts the patch as well. |
Thank you @piscisaureus, as for |
This will be a major change in practice, unfortunately. Consider code that accepts a string, 'url.parse's it, changes the pathname, and formats it, before handing the string to another function. This change will break that behavior, because "path" will be present on the parsed url object and will take precedence over "pathname". |
An example: var url = require('url');
module.exports = myCode;
function myCode(sourceURL) {
var parsed = url.parse(sourceURL);
parsed.pathname = '/updated/by/proxy';
return url.format(parsed);
} One solution might be to (hurk) start introducing setters and getters on properties of the Url instances returned by |
Wow~ neat @chrisdickinson the Perhaps we are able to add the watching after the current build is passed, could someone please help me with failures of testing on https://jenkins-iojs.nodesource.com/job/iojs+any-pr+multi/187/? Actually I could not find a way to reproduce and moreover unsure if the errors is introduced by this patch because the same errors is also printed at the following builds:
/cc @rvagg |
you can ignore all those reds, freebsd and armv6 have persistent problems that are yet to be resolved |
Okay, thanks for your telling, will do watching by following @chrisdickinson's comment. |
Hi @rvagg @chrisdickinson added setter/getter and related tests, could someone please take a look, thanks :) |
@chrisdickinson can you semver-* label this? Do you still believe it to be semver-major? |
btw, I didn't introduce setter/getter on other fields like host/hostname/href/etc., so if this is tagged as major, perhaps I can do this with those fields, though :) |
ping @chrisdickinson |
And actually when I run So I ran the following: # in node
> node
> url.parse('git+ssh://[email protected]:caolan/async.git#master');
{ protocol: 'git+ssh:',
slashes: true,
auth: 'git',
host: 'github.com',
port: null,
hostname: 'github.com',
hash: '#master',
search: null,
query: null,
pathname: '/:caolan/async.git',
path: '/:caolan/async.git',
href: 'git+ssh://[email protected]/:caolan/async.git#master' }
# in iojs with mine
> node
> url.parse('git+ssh://[email protected]:caolan/async.git#master').data;
{ protocol: 'git+ssh:',
slashes: true,
auth: 'git',
host: 'github.com',
port: null,
hostname: 'github.com',
hash: '#master',
href: 'git+ssh://[email protected]/:caolan/async.git#master',
path: '/:caolan/async.git',
pathname: '/:caolan/async.git',
search: null,
query: null } So I guess as you have said, there are some changes on npm, let's waiting for that action, Thanks for your quick updates :) |
What's the verdict on this PR? If it's acceptable for v2.x, can someone LGTM it? |
This looks like it would conflict a lot with the performance patch, so not LGTM :) |
I'm still waiting for that patch as well, i will fix conflicts once that would be merged |
@nodejs/tsc Since @petkaantonov has been too busy to do anything with #1650 and it's at a point where it needs rebasing anyway, I suggest we consider this for 3.x. |
If @petkaantonov and one or more of TSC agreed with, I would be so happy to working on #1650 from July so that we are able to work on this as well. This 2 has been suspended too long IMHO :) |
@Qard Hold up on merging this still, this will break a lot of downstream code. |
This PR re-added the commit d312b6d that reverted at #303, and in this time, I did cover the test with the case
git+ssh://[email protected]:<user>/<repo>
and let it passed:R= @bnoordhuis @evanlucas /cc @rvagg