Type error with Remix+Vite and Express Server

[stephen776]

Is there an existing issue for this?

• I have checked for existing issues https://github.com/getsentry/sentry-javascript/issues
• I have reviewed the documentation https://docs.sentry.io/
• I am using the latest SDK release https://github.com/getsentry/sentry-javascript/releases

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

• Setup Remix app with new vite config using express server
• Wire up express request handler using Sentry.wrapExpressRequestHandler

Expected Result

Should run without error

Actual Result

[na2hiro]

This is caused by the extended type for build field passed to createRequestHandler. It can now take a function which returns config object. remix-run/remix@9d516dd#diff-394afa15a85ef1282cf5f441ffbbf61c0a014a7bc9a4790be91ba004f1a21fb3R40

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 wrapExpressCreateRequestHandler for dev because you wouldn't use Sentry for reporting errors during development

const createHandler = vite
  ? createRequestHandler
  : wrapExpressCreateRequestHandler(createRequestHandler);
const handlerBuild = vite
  ? () => unstable_loadViteServerBuild(vite)
  : await import(BUILD_DIR + "/index.js");
app.all(
  "*",
  createHandler({
    build: handlerBuild,
    ...
  })
);

[stephen776]

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.

[Lms24]

Hi, thanks for reporting! We'll look into this soon.

@onurtemizkan please take a look at this after Hapi, thanks!

[onurtemizkan]

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:

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"),
    ...
  })

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?

[Lms24]

Yes +1 on the first workaround, sounds good to me. RE wizard, yes but let's tackle it in a follow-up PR