-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
feat(remix): Add Remix server SDK #5269
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
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 how simple wrapping the handlers are!
|
||
// debugger; | ||
const transaction = hasTracingEnabled() | ||
? startTransaction({ |
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.
startTransaction
should no-op if tracing is not enabled, so we don't need the ternary, we can just always call startTransaction
packages/remix/src/flags.ts
Outdated
declare const __SENTRY_DEBUG__: boolean; | ||
|
||
/** Flag that is true for debug builds, false otherwise. */ | ||
export const IS_DEBUG_BUILD = typeof __SENTRY_DEBUG__ === 'undefined' ? true : __SENTRY_DEBUG__; |
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.
We can remove this file. Please see https://github.com/getsentry/sentry-javascript/blob/master/CONTRIBUTING.md#debug-build-flags for more details.
We should just be able to use __DEBUG_BUILD__
everywhere now.
packages/remix/src/index.server.ts
Outdated
export { ErrorBoundary, withErrorBoundary } from '@sentry/react'; | ||
export { remixRouterInstrumentation, withSentryRouteTracing } from './performance/client'; | ||
export { BrowserTracing, Integrations } from '@sentry/tracing'; | ||
export * from '@sentry/node'; |
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.
let's move these exports to the top
type AppLoadContext = unknown; | ||
type AppData = unknown; | ||
type RequestHandler = (request: Request, loadContext?: AppLoadContext) => Promise<Response>; | ||
type CreateRequestHandlerFunction = (build: ServerBuild, mode?: string) => RequestHandler; |
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.
Are these all vendored in? Can we link to the code + git sha where we did this?
let res: Response | AppData; | ||
const activeTransaction = getActiveTransaction(); | ||
const currentScope = getCurrentHub().getScope(); | ||
|
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.
Instead of using optional chaining, let's just early return if there is no activeTransaction
. Same if there is no currentScope
} | ||
|
||
res = await origFn.call(this, args); | ||
span?.finish(); |
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.
Should we re-add back the transaction onto the scope?
currentScope.setSpan(activeTransaction);
span.finish();
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.
Why is optional chaining still needed here?
return async function (this: unknown, request: Request, loadContext?: unknown): Promise<Response> { | ||
const currentScope = getCurrentHub().getScope(); | ||
|
||
// debugger; |
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.
// debugger; |
}, | ||
"sideEffects": [ | ||
"./esm/index.server.js", | ||
"./src/index.server.ts" |
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.
Why do these have side effects?
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 took that from Next.JS SDK.
As I understand, we need to export browser / react stuff from index.server.ts
to make TypeScript happy on compile time, but it's not guaranteed that it'll be used on runtime. (index.client.ts
is used instead on the demo project).
So my guess is that flagging index.server.*
as side effects is to prevent a pre-bundler that may fail TS compilation.
} | ||
|
||
res = await origFn.call(this, args); | ||
span?.finish(); |
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.
Why is optional chaining still needed here?
Co-authored-by: Abhijeet Prasad <[email protected]>
Part 3 of #4894
Adds server side SDK for error tracking / performance tracing of Remix.
createRequestHandler
from@remix-run/server-runtime
which apparently is used by all server-side adapters of Remix.action
andloader
functions are patched as parameters ofcreateRequestHandler
.Tested:
action
/loader
requestHandler
Link to Transaction
Link to Event