url.parse() behavior change between node 0.10 and node 0.12, intentional?

[metamatt]

I note that in version 0.10.26 (at least), url.parse('/foo', true) always sets the .query property of the returned object to at least an empty object, but in node 0.12 (well, the tip of the current 0.12 branch which reports itself as 0.11.14-pre), url.parse() may set the .query property to null if the input URL string did not have a query string.

Demo output: https://gist.github.com/metamatt/e654f8ce7e25ed0fc906

I don't see any mention of this in the Node 0.11.13 docs or the API changes between 0.10 and 0.12 document.

I'm filing this issue to confirm whether the behavior change was known and intentional, and wondering whether the code should change or the docs should change.

NB: karma, at least, cares and is broken by the new behavior; see for example https://github.com/karma-runner/karma/blob/891a4528a51ba4806014a551ce8892072807bb5a/lib/middleware/karma.js#L40 which assumes the url.parse() result always has .query being an object it can look inside.

[trevnorris]

Seems that the fact .query was set to an empty object was simply an implementation detail, and some of the conditional changes made in v0.11 to make url.parse() faster have streamlined the conditional check. Hence it now skips the part of setting it to an empty object.

I'm not sure whether this should be considered a bug or not.

/cc @indutny @tjfontaine

[floverdevel]

karma is broken by this change, see karma-runner/karma#1182
and so i wonder where is the best place to fix this? nodejs? karma? both?

is this a regression from node, or it is intentional?

[trevnorris]

@floverdevel Doubt it was intentional, but it's also not a documented feature that .query will always be at least set to an empty object. It was just a byproduct of some performance enhancements. So I don't know if we'd call it a regression. Waiting for feedback from @tjfontaine or @indutny.

[gwicke]

The behavior should be consistent between the two parse paths. PR with a test & fix forthcoming.

[trevnorris]

Fixed by b705b73.