Aside, I didn't even get to the point of discovery on webpack or versioning. I imagine it'll end up looking similar to Next.js in that regard.

Lastly, relevant GH issue is here for SDK support: #4894

Hi @dcramer, thanks for taking a look at Remix. I'll do my best to help answer some of your questions here. I'll use the blues stack as a reference, though I'll also note that the purpose of the stacks is to show people one particular setup of Remix (running Express/node, hosted on fly.io, using Postgres as a db, etc.). There are actually many ways to use Remix with your fav host/framework/db/etc, but I'll leave that for another day. For now let's just get Sentry running in the blues stack.

Instrumenting the server

Let's start with the server. You can think of Remix like most typical React server-side rendering (SSR) setups. The server side goes like this:

• boot a server (usually node)
• request comes in, run the request handler (createRequestHandler in server.ts)
• fetch some data
  • Remix does this by running the loaders in app/routes in parallel
• render the page
  • Remix delegates to the user-defined function in app/entry.server.tsx to actually do the render
• send the response returned from the request handler
  • This is usually handled by your "server adapter", which in this case (the blues stack) is a standard Express middleware

Remix gives you direct access to both your server entry point and your React entry point for doing SSR. For purposes of instrumentation, you want the server entry point since this is the first code that runs when the server boots. From your guides on using Sentry with Node.js and with Express, just add the Sentry.init call to the top of your server.ts, use the Sentry Express middleware and you should be done.

Since you're running on node, you have full access to process.env, so just set your SENTRY_DSN as an environment variable in your server and use it directly:

import * as Sentry from "@sentry/node";
import "@sentry/tracing";
Sentry.init({
 dsn: process.env.SENTRY_DSN
 // ...
});
const app = express();
app.use(Sentry.Handlers.requestHandler());

Data loaders and actions

Your data loaders and actions also run server side in node, so capturing errors from them is the same as manually instrumenting any other node app.

// In one of your route modules...
export async function loader() {
 try {
 // talk to your db...
 } catch (error) {
 Sentry.captureException(error);
 }
}

Instrumenting the browser

The flow in the browser is a React hydrate workflow, which is standard when doing SSR in React. It goes like this:

• browser loads the HTML from the server
  • Remix gives you full control over the HTML in the response in app/root.tsx
  • the actual HTML markup from the set of current routes is rendered by the <Outlet> element
• browser downloads JavaScript
  • Remix includes the bundles you need for the page in the <Scripts> element
• React hydrates the page
  • Similar to the server, Remix gives you full control over the first code that runs in the browser in app/entry.client.tsx

As you noted above, there is a bit of extra work required to expose server environment variables to the client. Remix is unapologetically explicit here, not because we believe that "secrets are dangerous" but because we believe it's better to be explicit about exposing environment variables to front end code than to abstract it away in a config somewhere. In other words, we could create window.ENV for you, but then you'd probably wonder what it is and where it comes from. But if we allow you to create it yourself, you don't have to wonder about that.

Once you've done that (be sure to put your window.ENV <script> tag before <Scripts> in root.tsx), it's no different than your guide on usage with React. Just include your Sentry.init call immediately before you hydrate and you should be done.

import { hydrate } from "react-dom";
import * as Sentry from "@sentry/react";
import { BrowserTracing } from "@sentry/tracing";
import { RemixBrowser } from "@remix-run/react";
Sentry.init({
 dsn: window.ENV.SENTRY_DSN,
 integrations: [new BrowserTracing()],
 tracesSampleRate: 1.0,
});
hydrate(<RemixBrowser />,document);

The Sentry docs use ReactDOM.render, and not hydrate, but I'm assuming Sentry works the same in either scenario.

Re:

There are some issues with this approach as its already after application logic has begun to run

That is not correct. The code in app/entry.client.tsx is the first code that runs in the browser. If you need something to run even earlier than our output bundles, you can always put your own <script> tag in app/root.tsx (like you did for setting up window.ENV, you have full control over the HTML of the page), but that shouldn't be required here. The only bundles that load before the app/entry.client.tsx bundle contain your dependencies that you need to run the page, like React and React Router. They shouldn't have any side effects.

And with that, you should be done! Again, this is all pretty typical for a React SSR setup, so I'm hopeful you can help me understand where our docs are unclear on this so we can try to avoid confusion in the future.

Quick update: I missed /server.ts in the blues app. Added in an express middleware so now I'm able to get some degree of instrumentation (e.g. prisma queries are not showing up in any of the transactions, and it's a bit fuzzy which transactions are express requests vs browser requests atm). I think directionally I can follow the flow though, and should be able to get something going.

We wanted to give you a little help getting this integration going. One of our engineers got started on a Remix + Sentry integration that supports good server stack traces, transactions, and individual loaders and actions. He setup a sample account to test things out.

You can fork the repo here: https://github.com/jacob-ebey/remix-sentry

Server stack traces:

Transactions:

Individual loader/action duration:

Web vitals:

The approach here is to take the compiled output of our server build and wrap things as needed. So e.g. the loaders and actions for an individual route can be wrapped so you can see how long they take and automatically capture errors.

This is just the beginning of a Remix + Sentry integration, and we don't plan on working much more on this code. So I'd suggest you fork it or just learn from it and take what you learn to build your own integration. Hopefully this should get you moving in the right direction!

One last note, Remix is using esbuild, and so we'll need to somehow guide folks to update their build commands to include sourcemaps, and find a simplistic way to get them injecting sentry-cli into that pipline:

➜ ~/s/vanguard (main) ✔ esbuild --platform=node --format=cjs ./server.ts --outdir=build --sourcemap=external
 build/server.js 2.5kb
 build/server.js.map 3.9kb

We have made some progress on Sentry Remix SDK. And want to give an overview:

Client-side Instrumentation [Implemented]: #5264

• We're using our React SDK to capture/report errors.
• Implemented a router instrumentation specific to Remix projects, supporting parameterized route-based performance tracing.

Server-side Instrumentation [Implemented]: #5269

• Using our Node.JS SDK to error tracking.
• We're patching createRequestHandler from @remix-run/server-runtime, and wrap loader and action functions for performance tracing.
• This also works with database integrations, such as Prisma.

Sourcemap Uploads [In Progress]

We can't implement automated sourcemap uploads, like we do with Next.JS SDK, as we could not find anything to hook our release/upload process. Mainly because the inner esbuild configuration / parameters are not exposed to the Remix users. (ref: remix-run/remix#2168 (comment))

But the default esbuild configuration of remix build --sourcemap outputs a usable set of linked sourcemaps, that we can upload with sentry-cli without a complex configuration.

So we're planning to ship a mini CLI tool with Remix SDK, which uses sentry-cli under the hood to create a release and upload sourcemaps with it.

Can look something like:

$ sentry-upload-sourcemaps <release> options[--urlPrefix, --buildPath]

That script will have defaults for --urlPrefix and --buildPath, so users won't need to define them unless they alter the build path on remix.config.js. sentry-cli can still be used, in case a more complex configuration is needed.

Any input would be greatly appreciated!