-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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-dev/vite): use global Request
class in Vite dev server handler
#8062
fix(remix-dev/vite): use global Request
class in Vite dev server handler
#8062
Conversation
🦋 Changeset detectedLatest commit: f4b3f34 The changes in this PR will be included in the next version bump. This PR includes changesets to release 16 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Request
classRequest
class in vite middleware handler
Request
class in vite middleware handlerRequest
class in Vite dev server handler
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.
Thanks so much for the PR! I love that this gets us much closer to the other adapters.
|
||
return new ReadableStream({ start: start, pull: pull, cancel: cancel }); | ||
} | ||
installGlobals(); |
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.
Thanks for proceeding with this PR!
I was wondering about what's the future plan of this forced installGlobals
during vite dev
.
Node 18 ships fetch
, Request
, etc... globals, so I thought forcing polyfills here might not be appropriate and better to be opt-in choice by individual users.
Looking at what happened in other adapters #7009 (and also unstable-vite-express
currently has explicit installGlobals
in server.mjs
), the general direction seems to remove automatic/forced installGlobals
.
Currently this polyfills kicks in whenever remix vite plugin is loaded, so I think it's not even possible for custom server (during dev) to opt-out from installGlobals
currently.
Here is a quick repro:
https://stackblitz.com/edit/remix-run-remix-ws1uig?file=vite.config.ts
//
// vite.config.ts
//
let fetch1 = fetch;
import { unstable_vitePlugin as remix } from '@remix-run/dev';
import { defineConfig } from 'vite';
import tsconfigPaths from 'vite-tsconfig-paths';
let fetch2 = fetch;
export default defineConfig({
clearScreen: false,
plugins: [remix(), tsconfigPaths()],
});
let fetch3 = fetch;
// the log happens twice in parent and child compilers
// parent: true false
// child: true true
console.log(fetch1 === fetch2, fetch1 === fetch3);
EDIT: Current behavior would be essentially same as installGlobals
in vite.config.ts
, so in order to allow users to opt-out, I think I would prefer doing it in the template's vite.config.ts
#8119
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.
Yep, I was wanting to follow this up separately. Thanks for looking into this!
🤖 Hello there, We just published version Thanks! |
🤖 Hello there, We just published version Thanks! |
Closes: #7819, #8050
Currently in vite dev, remix handler makes use of
NodeRequest
class (based on undici) which is a different from globalRequest
and this breaks user code relying on... instanceof Request
.I noticed that this issue doesn't exist on express custom server since it uses its own way to construct
Request
instance based on globalRequest
inpackages/remix-express/server.ts
. So, I was wondering if it would make sense to do something similar for vite inpackages/remix-dev/vite/node/adapter.ts
as well.Probably there is a reason to use handler code based on solid-start, so if there is a known issue with this approach, please let me know.
testing strategy
I added a new test
integration/vite-dev-custom-entry-test.ts
to verifyrequest instance Request
is true during server entry'shandleRequest
.