https://serverless-stack.com/ logo
Join Slack
Powered by
What is it that determines whether it's production...
# general
r
What is it that determines whether it's production?
And is there a way to opt out? We use the Travel Time Debugging in Thundra to be able step through code with variables as they were at runtime for each request and that needs the source maps in place
a
Useless stack traces in production? 😢
r
They're not useless in our case
a
I think you misunderstood me Ross. I'm 😢 because Typescript stack traces are near useless without source maps.
r
Ah, yes, I see what you mean.
r
yeah this is a bummer. @thdxr what brought about the removing of sourcemaps part of #1267? Just trying to keep size down on deploy? Or is SST saying that sourcemaps in production are to slow and will not be supported at all?
Doesn't seem like we TS users have any option to get back mapped stacks in production now?
t
I can consider bringing them back - how are you guys using them?
I thought people were using esbuild plugins to ship them elsewhere
r
With Thundra's TDD feature, it uses source maps to determine the code to be able to posthumously step through
TDD=Travel Time Debugging
r
so for me its just seeing stack traces in TS. So I am using
Copy code
app.setDefaultFunctionProps({
    environment: {
      NODE_OPTIONS: '--enable-source-maps',
    },
    runtime: 'nodejs14.x',
  })
Then in our API calls we are using user permissions to determine if a request should send back stack traces or just simple messages
r
They don't have an upload feature, they expect them in situ
r
However I have no real performance data
Maybe this is horrible slowing down cold start times?
or even worse all invocations regardless?
t
That 
--enable-source-maps
is the thing that slows everything down. Both coldstarts + runtime
r
Is there any info on how that works?
t
r
hmmm what's a "large source file"
t
I'll bring it back though - I was under the impression that no one was using this. And under local testing we saw pretty bad slowdowns with a sourcemap that was ~1-2mb
r
Well now i am worried about using it haha
ok so looking at that issue, maybe we are better off using 
source-map-support/register
instead?
t
I haven't done full testing yet but apparently: https://www.npmjs.com/package/source-map-support?activeTab=explore still performs better
yeah
r
seems to have very little effect, oddly enough thats how i started then discovered the option
going back shouldn't be to hard. it would be nice if cloudwatch itself had a way to reason about this stuff
t
I know it should let you upload sourcemaps natively
r
I guess that doesnt help much for returning stakcs to the frontend... but that would probably be acceptable if we could see them in CW
a
I had always used the source-map-support library. Only recently switched to the node option because the library stopped working at some point (since switching to SST/esbuild from SF/webpack?)
r
but ok, this shouldnt be bad. we have build a abstract wrapper for all our handlers anyway. So we can just add the import in there and it should flip on, but we do need sourcemaps back in the build. pretty please 🙂
a
Or maybe it broke way back when I switched to Node 14, and I just didn't notice.
@thdxr I don't really see a reason to disable source maps via esbuild. We're choosing to generate them or not via tsconfig.json, and choosing to use source-map-support or the native option. Even with the poor performance being reported for the Node.js built-in option, it's pointed out that that performance hit only happens when you actually access an Error stack trace - which should only happen in production when something has already gone wrong.
t
The issue I linked is only part of the problem - it also slows down coldstarts. I rolled it back either way will do a release soon
a
I do set the tsconfig inlineSourceMap and inlineSources options to false. Thus the source maps (and not source) are not part of the interpreted runtime but rather in separate .js.map files. My understanding is that these will lazy load when needed. Only cold start hit then is copying the files over from S3 into the Lambda runtime. I haven't explicitly tested any of this, just my interpretation.
t
I'm not entirely sure if esbuild pays attention to those configs - it has its own configuration that we set
r
a
Oh. Wonder if that relates to why the source-map-support library approach stopped working for me.
t
The cold start issue occurs when you have the NODE_OPTIONS set
I think the issue is esbuild's api only shows two options to me inline vs external but their docs show a third option which is linked - that's probably what broke the source-map-support thing
a
I look forward to a solution. Thank you for looking at this thdxr.
t
I wonder if its just their typings that are broken, let me see what happens when I do linked
r
I would think we could go with linked for both dev and prod?
t
yeah I'm seeing if I can get that behavior, the typing is 
boolean | external | both | inline
r
it would help a little bit incase during dev you have to open that crazy .js file.
t
And I'm wondering if 
true
=== linked
r
right now my VSCode just dies when i try to open one haha
t
And if that's the case, the cold start issues I found maybe were just associated with inline
Yep that was it - 
true
is 
linked
- ok I'm going to do a release and then re-run my tests to see if coldstarts are fixed
I just released it as 0.59.4 and removed 0.59.2
a
Well now I have to upgrade from 0.57. CDK v2 wasn't urgent, but performance is.
r
FYI the upgrade for me was very easy. not sure how much custom CDK stuff you got, if you need to 
-alpha
a bunch of stuff but went pretty smoothly
r
Cool, so is there any configuration we need to do in 0.59.4?
t
no should work out of the box
r
@thdxr did you ever run those coldstart tests? is there any reason to use 
import 'source-map-support/register'
over
Copy code
environment: {
      NODE_OPTIONS: '--enable-source-maps',
    },
t
Yeah with the new implementation I don't see any of the issues I was seeing before
well, definitely not the severe ones
It seems to still slightly effect things but imo worth it for the clean stack traces
r
So any reason to use one over the other?
t
No reason, would just use NODE_OPTIONS now
r
great, thats what i was hoping. thanks!
2 Views
Open in Slack
PreviousNext
Powered by