Mapbox GL fixes: handle Request objects as URLs (and array buffer responses discussion)

[tombh]

Description

These are fixes I needed to get Polly working with Mapbox GL. So far the handling of an array buffer response is only for passthrough requests, not recording, is that a reasonable first step? There are no tests because I'd like some help thinking about how to test these.

Motivation and Context

I wonder if the handling of Request objects for URLs has already been considered? It's just that the the coercion of those objects into a URL string isn't handled simply by casting to a string?

I see in #183 that array buffer responses have already been considered.

Types of Changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist

• I have added tests to cover my changes.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• My code follows the code style of this project.
• My commits and the title of this PR follow the Conventional Commits Specification.
• I have read the contributing guidelines.

[tombh]

I think those test failures are linting errors on files not changed in this PR?

[offirgolan]

@tombh thanks for taking the time in opening up this PR!

I wonder if the handling of Request objects for URLs has already been considered? It's just that the the coercion of those objects into a URL string isn't handled simply by casting to a string?

This is definitely something that we should handle and should've been considered but I guess was missed. Can you split this into a separate PR so we can get this in faster as the ArrayBuffer work is going to be a bit more time consuming.

One note: PollyRequest does expect url to be a string or an object that can be casted into a url string. The logic to pass the correct url from a Request instance should be handled in the fetch adapter layer instead.

So far the handling of an array buffer response is only for passthrough requests, not recording, is that a reasonable first step?

Due to the current nature of the client server API (polly.server) even though we only target supporting binary data in passthroughs, it still flows through all the server route handlers and middleware. This can cause a pretty trolling behavior since the response body will be different depending on the recording mode.

Im not exactly sure how you want to proceed with this but supporting binary data would need to work across all recording modes in order to be merged in.

[tombh]

Ok I've removed the ArrayBuffer fix and added a test for the Request object fix. BTW is there not a way to run a single test? My laptop quite struggles with testem.

[tombh]

Again tests seem to fail because of an unassociated linting errors. But in fact I don't even seem to be able to see my added test in the logs.

[offirgolan]

Thanks for taking the time to land this @tombh. The CI failures are unrelated, we'll fix them separately.

BTW is there not a way to run a single test? My laptop quite struggles with testem.

Yeah, the current test/build system needs some work for sure. You can run a single test by using it.only on the test and then running yarn test -l Chrome or yarn test:ci -l Chrome.