Do not clone to scratch dir for typescript lamdas

[jacobduba]

Source maps are broken with Typescript Lamdas, causing line by line debugging to fail. My team spent a couple days completely stuck thinking we misconfigured something until we discovered it was a problem with the tool.

Since code gets copied to a "scratch dir" in /tmp esbuild points the sourcemap to the tmp directory.

{
  "version": 3,
  "sources": ["../../../../../../../../tmp/tmpdpzfnj5k/app.ts"],
  "sourcesContent": ["import { APIGatewayProxyEvent, APIGatewayProxyResult } from 'aws-lambda';\n\n/**\n *\n * Event doc: https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-lambda-proxy-integrations.html#api-gateway-simple-proxy-for-lambda-input-format\n * @param {Object} event - API Gateway Lambda Proxy Input Format\n *\n * Return doc: https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-lambda-proxy-integrations.html\n * @returns {Object} object - API Gateway Lambda Proxy Output Format\n *\n */\n\nexport const lambdaHandler = async (event: APIGatewayProxyEvent): Promise<APIGatewayProxyResult> => {\n    let response: APIGatewayProxyResult;\n    try {\n        response = {\n            statusCode: 200,\n            body: JSON.stringify({\n                message: 'hello world',\n            }),\n        };\n    } catch (err) {\n        console.log(err);\n        response = {\n            statusCode: 500,\n            body: JSON.stringify({\n                message: 'some error happened',\n            }),\n        };\n    }\n\n    return response;\n};\n"],
  "mappings": "yaAAA,wDAYO,GAAM,GAAgB,KAAO,IAAgE,CAChG,GAAI,GACJ,GAAI,CACA,EAAW,CACP,WAAY,IACZ,KAAM,KAAK,UAAU,CACjB,QAAS,aACb,CAAC,CACL,CACJ,OAAS,EAAP,CACE,QAAQ,IAAI,CAAG,EACf,EAAW,CACP,WAAY,IACZ,KAAM,KAAK,UAAU,CACjB,QAAS,qBACb,CAAC,CACL,CACJ,CAEA,MAAO,EACX",
  "names": []
}

The line-by-line debugger gets confused and skips through any breakpoints that were set.

PR does not clone the code into a scratch directory, compiles using the source directory into the build directory. I spent a lot of time looking for a flag inside esbuild that could point the sources content to another folder, but nothing existed.

Now, line-by-line debugging works.

{
  "version": 3,
  "sources": ["../../../hello-world/app.ts"],
  "sourcesContent": ["import { APIGatewayProxyEvent, APIGatewayProxyResult } from 'aws-lambda';\n\n/**\n *\n * Event doc: https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-lambda-proxy-integrations.html#api-gateway-simple-proxy-for-lambda-input-format\n * @param {Object} event - API Gateway Lambda Proxy Input Format\n *\n * Return doc: https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-lambda-proxy-integrations.html\n * @returns {Object} object - API Gateway Lambda Proxy Output Format\n *\n */\n\nexport const lambdaHandler = async (event: APIGatewayProxyEvent): Promise<APIGatewayProxyResult> => {\n    let response: APIGatewayProxyResult;\n    try {\n        response = {\n            statusCode: 200,\n            body: JSON.stringify({\n                message: 'hello world',\n            }),\n        };\n    } catch (err) {\n        console.log(err);\n        response = {\n            statusCode: 500,\n            body: JSON.stringify({\n                message: 'some error happened',\n            }),\n        };\n    }\n\n    return response;\n};\n"],
  "mappings": "yaAAA,wDAYO,GAAM,GAAgB,KAAO,IAAgE,CAChG,GAAI,GACJ,GAAI,CACA,EAAW,CACP,WAAY,IACZ,KAAM,KAAK,UAAU,CACjB,QAAS,aACb,CAAC,CACL,CACJ,OAAS,EAAP,CACE,QAAQ,IAAI,CAAG,EACf,EAAW,CACP,WAAY,IACZ,KAAM,KAAK,UAAU,CACjB,QAAS,qBACb,CAAC,CACL,CACJ,CAEA,MAAO,EACX",
  "names": []
}

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[jfuss]

@jacobduba I understand this may not be ideal but currently all the builders are setup to copy to a scratch directory and this is by design. I know we talked about changing this for ESBuild but believe we decided against it to keep the builders the same and try to find a different way to allow this behavior.

@mildaniel Is that the correct understanding?

[jacobduba]

@jfuss I understand that the solution is not ideal. When I first started digging into the issue was hoping an Esbuild flag would do the trick. No such thing (that I could find) exists.

[jfuss]

I chatted with @mildaniel yesterday about this. We have plans for adding opt in behavior for allowing a build not to copy into scratch for multiple runtimes.

We cannot accept this PR, as this will break container builds. As of now, if a build works locally it should also work in the container. Not copying would allow builds to access other parts of project. While this is probably for the best locally, if you (or someone else) has a dependency that needs to be build in a container, you can become stuck due to how we end up mounting what to build in the container. Which is not ideally and could break customers.

Going to close this PR, as we are not accepting these changes to the ESbuilder builder and instead the team will be looking to add an opt in behavior in the future (not timelines as of now to share).

[chris-fryer]

@jfuss @mildaniel We are also experiencing the same issue of being unable to set debug breakpoints in TypeScript code because of this issue. If you're not accepting this PR, do you have any suggestions of a workaround?

Without being able to set debug breakpoints in VSCode for TypeScript I don't think we can choose SAM for our upcoming project and will probably have to look at the Serverless Framework instead.

Cc @jacobduba

[jfuss]

@chris-fryer ESBuild is still in Beta, so we are still trying to figure out the best ways forward. Due to how everything works today (sam build and Lambda builders), I don't think there is a workaround for debugging at this point in time.

The team is discussing how we should handle this though and would note this is not isolated to ESBuild. Which is why we are leaning towards the solution that covers the wider use-case instead of just ESBuild. I know that is not ideal from your direct use-case but we feel is the better thing to do here.

[serkan-ozal]

Hi all,

In Thundra, we are also suffering from the same problem. Currently only workaround I see is that manually editing source map file to point to the workspace path ("../../../hello-world/app.ts") instead of "scratch dir".

Is there any other workaround and/or how we can automate this manual editing as part of sam build?

[tekwest]

We are not able to get breakpoints working even with the previous workarounds suggested here. Editing the source map file that is created during the build under .aws-sam/build/HelloWorldFunction/app.js.map by changing it to "sources": ["../../../hello-world/app.ts"] does nothing. And before even editing this file, an error during debug now comes up in the debug console, "Could not read source map..." and points to a missing app.js.map file in the hello-world folder where app.ts resides. Manually placing the app.js.map file here removes this error but trying to point to the app.ts in this app.js.map file is unsuccessful in getting breakpoints to work. This may be new behavior with this later version as I have not seen anyone describe this before.

This is with VS Code and SAM CLI, version 1.67.0. I'm not sure if the workarounds suggested are out of date with this latest version but any guidance is appreciated.

[dangeReis]

@jfuss almost two years later typescript debugging is still not working. If this was not the solution, what happened to finding an alternative?