"browser" package.json field about whatwg-url HOT 19 CLOSED

No, this package and the browser implemented URL object aren't necessarily the same (yet). No point doing this if the lib then produces inconsistent results. For example: chrome handles paths on windows differently than paths when running on Linux.

If there're problems with getting it to run as-is, sure, we can fix them, but this is not really a shim.

from whatwg-url.

How far off is https://github.com/Polymer/URL compared to this lib?

from whatwg-url.

It doesn't properly do encoding replacements according to UTS46 and it hasn't been updated in a while (the spec has though, so probably a bit off there; I'd assume file paths/non-special schemas are most likely impacted there).

from whatwg-url.

Thanks!

from whatwg-url.

How about providing a browser version that relies on the browser's URL class, but builds around it to provide the additional functionality? Would the path inconsistencies cause issues there?

from whatwg-url.

The lib doesn't provide any additional functionality though, it just properly implements what's needed for the spec. Also there's no way to half-parse a URL, so it's not possible to use the URL object for the host part and re-implement path ourselves.

What are you expecting of relying on the browser's URL class instead of this library?

from whatwg-url.

Lower file size for front-end apps, mainly.

from whatwg-url.

Also, this library already does half parse URLs -- query strings are optionally parsed and in different ways. Oops, misread what you'd said.

Can the inconsistently parsed paths not be used with this lib?

from whatwg-url.

That's not what I was refering to. To know what to half-parse you have to know where in the string the half you want to parse starts. But to do that, you need to parse the whole URL.

from whatwg-url.

Why re-implement path at all [for browsers]?

from whatwg-url.

See before

For example: chrome handles paths on windows differently than paths when running on Linux.

If you trust your browser(s) to follow the spec enough, you don't need this lib. If you want consistency, use it. There's no half-half.

from whatwg-url.

My goal is to use this for node, and use the browser's implementation when compiling with browserify.

from whatwg-url.

You can do that by writing a small file which just exports window.URL and specifying that to replace whatwg-url in your package.json.

from whatwg-url.

But there're functions available in this library that are not available in the browser implementations, are there not?

from whatwg-url.

No, the exported URL object should be totally equal. There are some exported util methods which you shouldn't have to worry about in browsers and wouldn't make sense to use with browser-native URL objects anyways.

from whatwg-url.

Okay, great!

The issue I've often run into with browserify is packages with larger dependencies -- I have to understand all parts of the sum to decide what should be excluded. I believe that this responsibility should fall into the package itself somehow. Someone wishing to browserify my lib will have to know to do what you described above.

from whatwg-url.

Shouldn't you be able to specify that in your lib so dependents don't have to know?

from whatwg-url.

How? My reading hadn't turned up anything a while back and even asking others led to a dead end.

from whatwg-url.

I'd assume the browser directive will work recursively - if you specify the whatwg-url redirection in your package, other packages requiring yours don't have to know about the whatwg-url vs URL problem.

from whatwg-url.