Add passthrough support #11
Conversation
| | 'patch' | ||
| | 'delete' | ||
| | 'options' | ||
| | 'head'; |
There was a problem hiding this comment.
Realized I can just use this from mirage. 😀
| @@ -52,6 +44,8 @@ type MirageServer = { | |||
| options?: unknown | |||
| ) => (request: RestRequest) => ResponseData | PromiseLike<ResponseData>; | |||
|
|
|||
| shouldLog: () => boolean; | |||
There was a problem hiding this comment.
I'm only defining parts of the MirageServer we actually care about / use here, to allow this to be as decoupled from upstream Mirage as possible.
|
Alright, this should be ready for review now whenever you have time, @bgantzler. I've implemented passthrough functions, and I'm preventing warning messages for requests for assets like the favicon and other static assets, which can happen during hot module reloading, for instance. |
|
@cah-brian-gantzler do you have time to review this, or should I just merge it and proceed? I'm fine with either approach, just want to make sure you have a chance to take a look if you want to. |
|
Im really out of touch with the MSW stuff. Thanks for doing this and asking, but I wouldnt wait on me (as I see you didnt 😄 ) |
This adds support for adding passthroughs to msw from a mirage config.
It's handled a bit similarly to pretender, which uses route-recognizer. This also does, but it builds up a
Mapof hosts to aMapof verbs to route recognizers. I'm using this in my own app with a pnpm patch, and it seems to work correctly, though it's a bit noisy because MSW tries to handle all requests, even for favicons and other resources on the local host.There are two main improvements to make still:
warnon unhandled requests to the local dev server.Not sure if either should be considered blocking on this PR, or we can open an issue to tackle them later since this is at least an improvement.