-
-
Notifications
You must be signed in to change notification settings - Fork 1.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
Type error with Remix+Vite and Express Server #9500
Type error with Remix+Vite and Express Server #9500
Comments
This is caused by the extended type for There's a workaround: await the vite server build. This might result in slower startup for dev, but there's no affect for Prod environment. wrapExpressCreateRequestHandler(createRequestHandler)({
build: vite
- ? () => unstable_loadViteServerBuild(vite)
+ ? await unstable_loadViteServerBuild(vite)
: await import(BUILD_DIR + "/index.js"),
...
}) Or you might even want to completely omit const createHandler = vite
? createRequestHandler
: wrapExpressCreateRequestHandler(createRequestHandler);
const handlerBuild = vite
? () => unstable_loadViteServerBuild(vite)
: await import(BUILD_DIR + "/index.js");
app.all(
"*",
createHandler({
build: handlerBuild,
...
})
); |
Thanks for the response.. I tried the second option of just not wrapping the handler in dev, but I am actually getting the exact same error in this scenario as well. |
Hi, thanks for reporting! We'll look into this soon. @onurtemizkan please take a look at this after Hapi, thanks! |
I just looked at our implementation, and it seems the most performance-efficient way to solve this is to await and extract the build before providing it to Sentry instrumentation. The whole async logic in this instrumentation is per-request, so there is currently no way to handle this without an API change or breaking performance. I'm +1 to the first workaround that @na2hiro mentioned:
We can mention it in the docs and also can automate this as a part of the wizard. Maybe a part of getsentry/sentry-wizard#495. @Lms24 what do you think? |
Yes +1 on the first workaround, sounds good to me. RE wizard, yes but let's tackle it in a follow-up PR |
This now breaks Remix v2.5.x HDR. |
Hey @appist-engineering would you mind creating a new issue with a couple more details please? Thank you! |
…10784) Resolves #10724 Related: #9500 Adds dev-mode support to Remix setups with Vite and Express. We currently accept Remix server `build` as an object to instrument. But Remix allows `build` as a synchronous or asynchronous function that returns the build object. Currently, it seems that functions are only used in development servers, and not in production. So, while this update slightly reduces `requestHandler` performance on dev servers, it does not on production builds. We need `build` in 2 places: 1- We instrument the loaders / actions on build, then we pass them down to the original implementations. 2- We use the `routes` inside them to create parameterised transactions. This update adds new internal wrappers around them to make sure that we don't miss out on the returned / resolved values in case `build` is a function, for both cases. This PR also adds a new E2E test application using the latest Remix version and Vite, and it runs the tests on `dev` mode. We also need a documentation update to reflect this, if it gets merged.
…10784) Resolves #10724 Related: #9500 Adds dev-mode support to Remix setups with Vite and Express. We currently accept Remix server `build` as an object to instrument. But Remix allows `build` as a synchronous or asynchronous function that returns the build object. Currently, it seems that functions are only used in development servers, and not in production. So, while this update slightly reduces `requestHandler` performance on dev servers, it does not on production builds. We need `build` in 2 places: 1- We instrument the loaders / actions on build, then we pass them down to the original implementations. 2- We use the `routes` inside them to create parameterised transactions. This update adds new internal wrappers around them to make sure that we don't miss out on the returned / resolved values in case `build` is a function, for both cases. This PR also adds a new E2E test application using the latest Remix version and Vite, and it runs the tests on `dev` mode. We also need a documentation update to reflect this, if it gets merged.
…10784) Resolves #10724 Related: #9500 Adds dev-mode support to Remix setups with Vite and Express. We currently accept Remix server `build` as an object to instrument. But Remix allows `build` as a synchronous or asynchronous function that returns the build object. Currently, it seems that functions are only used in development servers, and not in production. So, while this update slightly reduces `requestHandler` performance on dev servers, it does not on production builds. We need `build` in 2 places: 1- We instrument the loaders / actions on build, then we pass them down to the original implementations. 2- We use the `routes` inside them to create parameterised transactions. This update adds new internal wrappers around them to make sure that we don't miss out on the returned / resolved values in case `build` is a function, for both cases. This PR also adds a new E2E test application using the latest Remix version and Vite, and it runs the tests on `dev` mode. We also need a documentation update to reflect this, if it gets merged.
…10784) Resolves #10724 Related: #9500 Adds dev-mode support to Remix setups with Vite and Express. We currently accept Remix server `build` as an object to instrument. But Remix allows `build` as a synchronous or asynchronous function that returns the build object. Currently, it seems that functions are only used in development servers, and not in production. So, while this update slightly reduces `requestHandler` performance on dev servers, it does not on production builds. We need `build` in 2 places: 1- We instrument the loaders / actions on build, then we pass them down to the original implementations. 2- We use the `routes` inside them to create parameterised transactions. This update adds new internal wrappers around them to make sure that we don't miss out on the returned / resolved values in case `build` is a function, for both cases. This PR also adds a new E2E test application using the latest Remix version and Vite, and it runs the tests on `dev` mode. We also need a documentation update to reflect this, if it gets merged.
…10784) Resolves #10724 Related: #9500 Adds dev-mode support to Remix setups with Vite and Express. We currently accept Remix server `build` as an object to instrument. But Remix allows `build` as a synchronous or asynchronous function that returns the build object. Currently, it seems that functions are only used in development servers, and not in production. So, while this update slightly reduces `requestHandler` performance on dev servers, it does not on production builds. We need `build` in 2 places: 1- We instrument the loaders / actions on build, then we pass them down to the original implementations. 2- We use the `routes` inside them to create parameterised transactions. This update adds new internal wrappers around them to make sure that we don't miss out on the returned / resolved values in case `build` is a function, for both cases. This PR also adds a new E2E test application using the latest Remix version and Vite, and it runs the tests on `dev` mode. We also need a documentation update to reflect this, if it gets merged.
Is there an existing issue for this?
How do you use Sentry?
Sentry Saas (sentry.io)
Which SDK are you using?
@sentry/remix
SDK Version
7.79.0
Framework Version
No response
Link to Sentry event
No response
SDK Setup
No response
Steps to Reproduce
Sentry.wrapExpressRequestHandler
Expected Result
Should run without error
Actual Result
The text was updated successfully, but these errors were encountered: