-
Notifications
You must be signed in to change notification settings - Fork 2
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 support? #2
Comments
What module is "url" here? Because if it is the Node.js core module "url", then it doesn't even have a constructor... which would indeed throw an Error. |
"url" is Node's url, which in v7.x has an implementation of
|
Ah, yeah, sorry, I missed the destructuring. I'll give it a quick look over lunch if I can but I see no reason why it shouldn't just work unless the experimental implementation of the URL constructor in Node |
It shouldn't be buggy, especially when we're so close to 8.x which will drop the "experimental". |
So I am able to reproduce this, though I still don't fully understand why. The primary issue here, though, is the URL objects apparently do not have any keys (owned properties), which seems very strange semantically. For example, |
They're property descriptors, accessed via Object.getOwnPropertyDescriptor(URL.prototype, "hostname").get |
I've written isurl which will come in handy if you need to special case something. |
Why is |
FYI, I opened an issue for this on lodash's issue tracker to see if they would consider supporting these URL objects internally. If not, then I can consider adding them as a special case here. If they weren't potentially so prolific in the future, I'd definitely vote against it as they seem ridiculously un-semantic (utilizing inherited property descriptor getter functions rather than normal owned properties (or owned property getters)). |
Because anything lower has reached end-of-life: https://github.com/nodejs/LTS#lts-schedule1 |
So, basically I think I would just add something like the following (only more optimized, obviously) around index.js#L27: if ( Object.prototype.toString.call( actual ) === '[object URL]' ) {
actual = require('url').parse( actual.href );
}
if ( Object.prototype.toString.call( expected ) === '[object URL]' ) {
expected = require('url').parse( actual.href );
} |
|
Isn't this only an issue for URL objects that come out of Node v7+? |
I suppose it doesn't handle a |
Yes, you're right. I just tested deep-nested instances of whatwg-url and it passes fine. |
It works with whatwg-url because that module produces sane (semantic) URL objects that have owned properties, unlike the real WHATWG URLs in Node 7.x and the browser that use weird getters instead. |
Will |
If you were using something like Browserify/Webpack, then I assume they will add appropriate support to make it work in the future if it is not already there today. If you are not using those tools, then I'd imagine the answer is no. That said, this module (chai-deep-match) currently doesn't work in the browser either.
Oh, bummer. Hmm.... |
@stevenvachon: To the best of your knowledge, is it possible for 2
|
Nope to both. |
I just realized that my answer was not necessarily correct. For an assertion library, I would say that two non-matching url1 = 'http://host/?p1&p2'
url2 = 'http://host/?p2&p1' Some servers may not be configured correctly (according to specification and common best practices) by treating those as two URLs different, when they should technically be the same. |
@JamesMGreene would |
@JamesMGreene any progress on this? |
@stevenvachon Just to be clear: are you only expecting the URLs to be considered matching if they are full matches vs subsets? For example, would you want the following to be considered a match?
|
Full match, but a subset might be useful as an additional method somehow. You might be able to use my--currently incomplete--url-relation for a pre-release. I'll be fixing its edge cases soon. |
Published as |
The text was updated successfully, but these errors were encountered: