New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(remix): Resolve Remix Request API compatibility issues. #6215
Conversation
size-limit report 📦
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like this approach! (For everything else, we just special-case our parsing function to high heaven, but really, the responsibility for framework-specific stuff should lie with the framework.)
One small question, but otherwise LGTM!
// chunked encoding is handled by Node.js | ||
const search = getSearch(parsedURL); | ||
|
||
// Manually spread the URL object instead of spread syntax |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this your choice or just copied from their implementation? (Just curious why the spread operator is being avoided.)
Same question with the @ts-ignore
s below.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Neither of the above is a blocker (just my own curiosity), so I'm going to go ahead and merge this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, they are copied from the original implementation. Not sure what's the reason for spread operator there, but it seems they have kept the approach of node-fetch
.
<comment deleted because I accidentally pasted the |
Ref: #6139 and #6139 (comment)
This PR is not a complete solution for all issues mentioned in #6139, but it aims to solve the parsing issue, which should fix auto-instrumented usage.
Remix uses its own implementation of Fetch API on both back-end and front-end, which has different structures storing
headers
andurl
. That has causedRequestData
integration to not work properly on Remix projects.I first attempted adding support to the core parser, and
PolymorphicRequest
. But it seemed very complex (if possible), because we have to type Proxy objects and Symbols, which our current TypeScript version doesn't fully support.So, I vendored / modified a couple of unexported utilities from
@remix-run/web-fetch
, to convert request objects to a compatible structure that we can consume inRequestData
integration.