Is it possible that by enabling lambda source maps (like suggested here -

setDefaultFunctionProps

) the live VScode lambda debugging gets broken? When I remove that environment setting from the stack and deploy it, the debugger starts to catch the breakpoints. When I return it back and deploy it, it doesn’t catch any breakpoint. Is VScode lambda debugger be taking into considerations the source maps anyhow when handling the breakpoints?

I think @Ross Coundon ran into a similar issue with VS Code when sourcemaps are enabled. https://serverless-stack.slack.com/archives/C01HQQVC8TH/p1641936211054700

Can you try adding those NODE_OPTIONS to sst start

Alright, I will try setting the

NODE_OPTIONS

for sst start. 👍 Let me know if you have any other ideas. 🙂 I would like to have same IaC definition for production stack as for the debugging stack. Otherwise I would have to add the environment variable conditionally to hotfix this issue which is not ideal… 🤷‍♂️

You can have it for both so you won't need to do anything conditionally. BTW conditionally changing the iac isn't too hard can do

if (app.local)

to tell if it's running in local mode

Unfortunately adding

NODE_OPTIONS

with value

--enable-source-maps

to the debugger environment doesn’t help.

You can have it for both so you won’t need to do anything conditionally.

Can you elaborate? I have set that for both, but the debugger doesn’t work in that case.

export default function main(app: <http://sst.App|sst.App>): void {
	app.setDefaultFunctionProps({
		environment: {
			NODE_OPTIONS: '--enable-source-maps'
		}
	})

The

if

serves as a hotfix - true. But if we are about to start building all our new company production systems on SST I would like to minimize the number of hotfixes.

That comment wasn't for your specific issue. I just meant sometimes you need sst start to deploy a slight variation compared to prod. This doesn't require env variables

I tried to do some digging and I found out this commented code

// NODE_OPTIONS: "--enable-source-maps",

https://github.com/serverless-stack/serverless-stack/blob/c31d1575991ea6358e55a6682b6159340c46274c/packages/core/src/runtime/handler/node.ts#L263 Any idea why did you comment that out? @thdxr

➕ Just wanted to confirm same behavior on my end with debugger on vscode when source map is enabled. Work around as mentioned was just disabling sourcemap locally with an env var.

@Frank I think we should look into and create an issue?

Yup.. taking a look at the issue right now

Yeah, that's what I was seeing.

Thanks @Ross Coundon. I think the issue is the Lambda’s

NODE_OPTIONS

when set

environment: {
  NODE_OPTIONS: "--enable-source-maps"
}

overrides the

NODE_OPTIONS

set by VSCode:

NODE_OPTIONS=--require "/Applications/Visual Studio <http://Code.app/Contents/Resources/app/extensions/ms-vscode.js-debug/src/bootloader.bundle.js|Code.app/Contents/Resources/app/extensions/ms-vscode.js-debug/src/bootloader.bundle.js>" --inspect-publish-uid=http

Ah, possibly. I remember a PR I'd submitted a while back where you asked me why I use += for NODE_OPTIONS and that was why 😁

Ah gotcha. Just released v0.66.1 with the fix to merge Lambda’s

NODE_OPTIONS

settings with VS Code’s

NODE_OPTIONS

settings.

I confirm I also see unbound breakpoint 👍 I will let you know when I get back to it. Thank you for fixing it 🔝

Well, embarrassingly, I just discovered that

+= 'something'

on an undefined string yields the result

'undefined something'

so it turns out what I suggested was a rather crappy approach

no worries, I did a smarter implementation in the pr 😜 https://github.com/serverless-stack/serverless-stack/blob/master/packages/cli/scripts/start.js#L609-L614

Show off 😉