Should bent be split into Node.js and browser versions?

[aral]

I noticed, while adding responseHeaders to error objects (https://github.com/mikeal/bent/pull/93/files), that the Node and Browser implementations differ in what the responses return. On Browser (unless I’m missing something), I couldn’t see the same details in the response objects as on Node. (For example, no header information.)

Not having looked at depth into the underlying Browser implementation, I’m wondering:

• Should bent be split into two modules (node, browser) with different expectations
• Should the browser and node implementations be made to match perfectly (if possible)

Thoughts?

(This is not a huge issue for me personally and definitely not a hill I wish to die on as I’m only using it in Node but I’m assuming it might be confusing for folks who use it in both Node and Browser if they encounter different behaviour.)

Please feel free to close if not a priority for project goals.

[mikeal]

So, this is a little tricky.

While I strive for parity, I do find it a little aggressive to actually prevent exposing browser/node.js specific details in each environment.

Right now, if you don’t do use body decoding, the response object is the native Node.js response or the Fetch response object, which obviously have different API’s. My goal is, over time, to simply decorate each object to provide consistent interfaces across both. We’re already doing this for a bunch of properties but I suspect some are still missing, and we’re missing even more useful info on StatusError which you’ve obviously noticed.

Anywhere that we don’t have consistently available access to information in both environments should be considered a bug.

[mikeal]

Just pushed a big improvement in this direction #96

Not sure if that resolves this issue for you or not, but it’s a move in the right direction.