Hi guise, I’m trying to build my first simple pack, and I built a structure of my pack that I import files with code into pack.ts using something like this:
import * as schema from “./schema”;
import * as fetcher from “./fetcher”;
I have some problems with my code in the fetcher.ts file.
I’m trying to debug this code using Visual Studio functionality for this. I installed a “TypeScript Debugger” extension, and create a launch.json file with this configuration:
I put some breakpoints into pack.ts and fetcher.ts files.
When I open the pack.ts file and start debugging code execution stops on breakpoints in the pack.ts file, but code execution isn’t going to the fetcher.ts file.
When I open fetcher.ts and click on the button to start debugging, I see no actions, no error messages, no debugging console, etc.
Could you tell me the methods and ways how to configure debugging locally?
Because in doc wrote just about using console for debugging.
I think this method is longer than doing it locally because after each editing of code you have to rebuild and upload a new version of the pack to coda.io and see how it works.
Hi @Andrew_Golovchenko - Welcome to the Coda community! I’m pretty new to using the debugger in VSCode, but it does seem to be possible with a Pack. There is one bug I found that we need to fix, but here’s what I did that mostly works:
Add a debugger; statement to your code where you want to add a breakpoint. Actual breakpoints don’t work until the bug is fixed.
Open a JavaScript Debug Terminal (run Debug: Create JavaScript Debug Terminal from the command pallete).
Run the npx coda execute command passing in the flag --vm=false. For example:
npx coda execute --vm=false pack.ts Hello "Eric"
The debug terminal should kick Node into debug mode and attach the VSCode debugger to it. The code will break at the debugger statement.
The --vm=false is important here, since normally the code runs in a virtual environment that emulates the limited runtime your Pack executes in when uploaded. However the debugger isn’t wired up to that runtime currently. Disabling the VM allows the code to run in the normal Node.js runtime, which while not as accurate allows for debugging.
The issue I discovered is that the generated source map isn’t configured correctly at the moment, so the debugger can’t correctly link up the source to the original pack.ts file. This leads to a “duplicate” file appearing when debugging and breakpoints not working. It should be relatively simply to fix this and I’ll tackle in this week.
I did some more digging, and the mismatch issue I ran into seems to be specific to my Windows setup. Still a bug to fix there, but it doesn’t appear to affect all environments.
