Can anyone point me in the right direction for typescript sourcemaps for lambda functions using sentry (and ideally, gitlab)? (Paging @Sam Hulick as my slack searching suggests you might have some war stories to share!) I have enabled source maps for my functions in SST using

NODE_OPTIONS: '--enable-source-maps'

, and have notified Sentry that there is a release (using the git SHA as the release name). I have also connected Sentry and Gitlab using the official integration. When I force an error from a lambda function, Sentry associates it with the right release, and the release has the full commit history since the previous commit. Source maps are also semi-working, because Sentry tells me the error is in

/backend/services/error.ts

at line

16:9

, instead of

/backend/services/error.js

at line

1928379128:1928391823

or whatever. But despite the typescript path being the exact same path as the source file in my gitlab repository, Sentry isn’t showing any source (beyond the stack trace). I have tried uploading source maps manually to sentry, but the source maps are for

/backend/services/error.js

(note the

js

extension) whereas with source maps enabled, the error reports itself as coming from

/backend/services/error.ts

, so my manually uploaded source maps don’t get picked up. I have also tried turning off

--enable-source-maps

, and just uploading the source maps to sentry, but that also doesn’t work. (Sentry complains that it can’t find the

.js

file in my gitlab repository). Having the correct filename and line numbers is much better than nothing, I was just wondering if anyone’s managed to get the source code to display in Sentry as well.

yo I gotcha covered 🙂 with SST, you’ll need an esbuild plugin

Thanks @Sam Hulick I will give that a try!

Thanks @Sam Hulick @Athol Birtley this is super useful!

sure @Frank! @Athol Birtley sorry, forgot the Sentry rewrite part! so many parts to this 🙂 I’d recommend this:

const lambdaPathPattern = /^(?:async\s+)?\/var\/task\//;

[...]
new RewriteFrames({
  iteratee: frame => {
    if (lambdaPathPattern.test(frame.filename!)) {
      frame.filename = frame.filename!.replace(
        lambdaPathPattern,
        'app:///'
      );
    }

    return frame;
  },
}),
[...]

i've not had any issue with seeing sourcemaps that are part of the function bundle (as a .map file) - using

NODE_OPTIONS: "--enable-source-maps

Interesting, @Mischa Spiegelmock ! What I found when doing that was that Sentry reported the error in the correct location (eg

/backend/services/myendpoint.ts:10

) but that it did not display the source code where the error occurred, because the source map was for a

.js

file, ie

/backend/services/myendpoint.js.map

But my bigger question is how is your source map data making its way to Sentry? Are you uploading them as part of the build process (and if so what are you naming them)? Does Sentry have the ability to “peek inside” a deployed lambda function? Or can the stack trace data be somehow augmented with the source map context (eg the stack frame line plus five lines either side)? My understanding - which could well be mistaken - was that Sentry needed a copy of the source map file in order to display the code where the error occurred.

i just look at the stack trace, i was bundling sourcemaps without source

Ah right! Yes, if you just want the correct file names and line numbers in the stack trace, then

NODE_OPTIONS: "--enable-source-maps

works well. But if you are lazy and also want the source code from that line (and surrounding lines) shown to you inside Sentry, then I think you need to go through the steps Sam has outlined above.

It would be pretty cool if SST could have an option to split out the sourcemaps and upload them to sentry AFTER the deployment (so you can get your code updated faster)

@Mischa Spiegelmock this is what I wish most JS frameworks would do: let me specify a source map output directory, and it can dump them all there. then I can decide what to do with it (upload to Sentry or Rollbar, etc). it would be nice if SST some day had an option you could set in sst.json pointing to where the source maps should go. (@Frank) then I could get rid of my esbuild plugin 🙂

^ I'm investigating this

@thdxr you talking about uploading the source maps in the Lambda package? it would be cool if we could exclude those from the bundle

I just added the ability to turn them off but you can't do that since you need to copy them over right? That's what I mean I want to support dumping them into a folder

hmm.. unsure of the order of how things happen. my esbuild plugin copies the .map files into a separate folder, so it wouldn’t hurt if the .map files weren’t included in the Lambda zip files

the option right now disable esbuild from generating them so I think it would break your setup

ahh, dang. well, if it were possible to dump the .map files into a folder instead of in the Lambda bundle, that would work. so e.g. if

sourcemapOutputDir

is not defined, it just gets included in the Lambda zip files

here's what ya get with Prisma lol... x50 functions

I’ll second this 😄 the ability to generate sourcemaps, but not deploy them in the lambda bundle, would be handy.

i'm going to solve it by getting fiber installed thursday lol