jsdom
Reduced version of library that does not require whatwg-url
I'm trying to add support for data URLs in node-fetch, which currently has zero dependencies. I would of course like to use this module, but this brings in the whatwg-url module as a dependency, which is huge and in many cases these days unnecessary because of the native Node.js URL class.
@domenic would you be open to the idea of having a sister package to this one that assumes the input is a valid serialized URL, i.e., a version of data: URL processor starting at step 3, and possibly have the main data-urls package depend on it for most of the logic?
I'd like to understand what you're hoping to accomplish a bit better here. If the goal is for node-fetch to continue having zero dependencies, that won't work. If the goal is to avoid having more than just this module as a dependency, that won't work either, as whatwg-mimetype is a second dependency.
data-urls and even whatwg-mimetype are fine, as they are not too big. But whatwg-url (specifically tr46) is pretty big.
I believe doing this makes sense as we would presumably want a well-written package like this to be useful to smaller projects too, for which the weight of whatwg-url would be prohibitive.
What would node-fetch do in versions of Node that don't support the URL constructor?
So in general I'm not super-enthusiastic about this, but am not opposed, if someone else does all the work. I think I'd be happiest if we figured out a way to keep all the code in one repository? Maybe using that lerna thingy? But maybe that's too much trouble.
I assume it wouldn't be sufficient to just split out this package into multiple files within the package, that could be required independently? That would decrease the hypothetical bundle size of node-fetch, even if the on-disk installation size stays large.
That would decrease the hypothetical bundle size of node-fetch
That would be an edge case, since few people bundle modules intended for Node.js usage.
even if the on-disk installation size stays large.
That's exactly what I'm trying to avoid.
I'd like to second this request, but from a different performance perspective: I want to parse a data url in the browser, and don't want to include the whole whatwg-url package in my bundle, as it's quite a lot for users to download and seems redundant. Ideally, I wouldn't need a package to parse data URLs in the browser at all, but the WHATWG data url parsing algorithm doesn't seem to be exposed in the browser anwhere, except through fetch, which is not a reliable way to parse given that CSP connect-src could cause the fetch call to fail.
