https://serverless-stack.com/ logo
Join Slack
Powered by
I know SST is deploying JS + maps to Lambda, but i...
# help
s
I know SST is deploying JS + maps to Lambda, but is there anything going on internally during deployment to register those source maps w/ Lambda so they’re associated w/ the JS file? if so, is there a way to disable that? I think it’s interfering with Sentry, maybe. still investigating though
is SST using this?
t
It might be a dependency of esbuild
I can see it in yarn.lock
We need to provide a way to disable esbuild sourcemap probably
s
well, that’s ok.. esbuild needs to generate sourcemaps. just as long as no other part of SST is running 
require('source-map-support').install()
actually.. it would be the Lambda function that executes that. so I don’t think this is an issue
actually, Sentry isn’t even reporting anymore.. ugh. this is my never-ending battle with source maps 😄
@thdxr not sure how SST is setup.. with Serverless Framework, Lambda errors would send the full path, e.g. 
/var/task/src/sub1/sub2/thing.js
. but.. with SST I just get 
/var/task/thing.js
. and so when it reports errors to Sentry, it doesn’t have the full path and hence doesn’t match the source maps there, which are full paths.. 
~/src/sub1/sub2/thing.js.map
so, in a fresh SLS project.. this is what the Lambda package contains:
Copy code
0  08-26-2021 19:24   src/
        0  08-26-2021 19:24   src/functions/
        0  08-26-2021 19:24   src/functions/hello/
     5186  08-26-2021 19:24   src/functions/hello/handler.js.map
     1220  08-26-2021 19:24   src/functions/hello/handler.js
t
This is likely because we bundle everything into a single file
Oh I see what you're saying
s
yeah, it’spreserving the folder structure
that’s super important. because if I just flattened the folder structure for the source maps, there could be overwritten files. e.g. if I had 
src/wow/thing.js
and 
src/hey/thing.js
, one would overwrite the other.. so the folder structure is important
t
Right, I'm working on a v2 of our runtimes and this is something that'll be really easy to enable with it. Let me see if I can add an option to the existing one
Will make an issue
Thinking this maybe should be default behavior since it's invisible
s
yes, I agree. so it works out of the box, and is easier to set up with third party error reporting
@thdxr dude. DUUUUDE
I’m such a dummy
so, this whole asynchronously getting the release to use in 
Sentry.init
.. I found the simplest way ever
add this to your 
Sentry.init()
options:
Copy code
beforeSend: async event => {
    const release = await getSsmParameter('/global/sentryRelease');
    event.release = release;
    return event;
  },
why did I not think of this before? 😄
2 Views
Open in Slack
PreviousNext
Powered by