Bug: inline sourcemaps are broken

[rob3c]

The AWS CDK inline sourcemaps are broken. This is because sourcemaps are based on the original typescript source files, while the inlined typescript source code has been stripped down in some way so they're shorter and don't align with sourcemap locations.

This mismatch prevents debuggers from stepping through source correctly. It also causes wrong code excerpts to appear in CDK CLI error output. Both of these problems can make it much harder to debug a CDK app than it needs to be. That's too bad, because the CDK is a wonderful tool, and simpler debugging would make it even better!

Reproduction Steps

There are different ways to show the problem for a given CDK version. I've checked 1.91.0 (currently the latest 1.x) as well as the earlier 1.85.0 release. I'll use the vscode debugger below with screenshots, which seems simplest here.

(Note that I created the annotations in the screenshots before writing this text, and some imprecisely refer to the original source as 'correct' and the inline source as 'wrong' in terms of sourcemap locations. Of course, what really matters is that sourcemap locations align with the inlined code, not that they necessarily match the original files.)

Repro 1

1. Find the source for the version we're using as a reference. For example, use the github branch picker online, or clone locally:

git clone https://github.com/aws/aws-cdk.git
git checkout tags/v1.91.0
# No need to waste time building here, we just want to see source files

2. Initialize and build a minimal CDK app to debug, then open in vscode:

cdk init app --language typescript
npm run build
code .

3. Switch to the debugger tab in vscode, and create a new nodejs launch config.
   

4. Set a breakpoint at the new cdk.App call:
   

5. Step into the cdk source for the App constructor. This is really the inline typescript source at the end of the js file. Notice that the debugger has placed us at the end of the file. That's because the 101:5 location it tries to navigate to is based on the original source that has 147 lines, but the debugger uses the inline source that only has 86 lines:
   

6. Here's a screenshot from the original v1.91.0 app.ts source file, confirming that the sourcemap line:column indicator in the stack (101:5) matches it:
   

Repro 2

As a further example, I added this code to force a cdk synth CLI error. The fact that this causes an error is surprising to me, since it seems I should only need to create a single HostedZone instance once using fromLookup that I can pass to multiple stacks via props. Anyway, I'll probably create a separate issue for it. Debugging it is what prompted reporting this issue.

1. Here's the main source change:
   

2. Here's the cdk synth CLI output stack trace with incorrect source code excerpt. In the screenshot, notice all stack locations match the original typescript source but not the inline source:
   

3. Here's the reported line 191 from the original source, which is the correct source of the thrown error:
   

4.a And here's where the code excerpt text is from in the original source at line 369:

What did you expect to happen?

I expect the sourcemap locations to match the inline source code exactly.

What actually happened?

The sourcemaps do not match the inline source code, which causes two problems:

1. The debugger cannot step through the source correctly, causing a debugging nightmare lol.
2. Source code excerpts in stack trace errors during CDK CLI operations are wrong and misleading.

Environment

• CDK CLI Version : 1.91.0 (doesn't matter but also 1.85.0)
• Framework Version: 1.91.0 (also earlier in at least 1.85.0)
• Node.js Version: 14.15.4 (doesn't matter but also 12.18.3)
• OS : Windows 10 (doesn't matter but also macOS)
• Language (Version): <!-- TypeScript 3.9.9 (doesn't matter but also 3.9.7)

Other

It appears that there's a code reduction step in the build process that's stripping down the source that ultimately gets inserted inline in the js files. Unfortunately, it seems the sourcemaps are created before this happens, so they match the original source instead of the inlined source. Hopefully, there may be a simple fix by just reordering some build steps, but maybe that's just wishful thinking :-)

---

This is 🐛 Bug Report

[MrArnoldPalmer]

Adding @rix0rrr cause I know he uses the vs code debugger and may have a better idea of whats going on here.

[rix0rrr]

Don't use it a lot :)

I think what's happening here is that the source maps get generated by TSC based on the original TypeScript source it sees, but then jsii applies some additional transforms to the JavaScript source which cause the sourcemaps to desync.

jsii/packages/jsii/lib/compiler.ts

Line 268 in f958f5a

assembler.customTransformers,

This is only a guess, but that is my guess. We'd estimate this by looking at the displacements of where VSCode thinks the source is, and then estimating the number of characters that the (deprecated) and runtime-info-related generated code occupy and seeing if they are about the same size.

This should probably be bumped to the jsii repository, and the solution is probably of the form of doing the transforms earlier, or forcing the source maps to be recalculated. @RomainMuller wdyt?

[rob3c]

Thanks @rix0rrr that confirms my suspicions. I appreciate your quickly identifying jsii transformations as a likely cause of the problem, and sharing a relevant source location is a nice bonus!

Should I also create an issue there that links here, or is someone from the CDK team already planning to do it?

I see there's a jsii issue label here that can be applied for cases like this. There are several issues labeled with it that remain open (my project mgmt pref too), so I won't try to close this issue yet.

[MrArnoldPalmer]

@rob3c go ahead and create an issue in jsii and close this in favor of that when done.

[RomainMuller]

Transferred to the jsii repository.

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.