Improvement suggestion: add source paths

[willi1s]

I use the duktape api duk_peval_file() this sends the full path to the .js file to the debugger, but the path on my target platform does not match my local directory.

The default duktape debugger can have a list of source search paths, and it strips the file path off the string and attempts to match the file name in the supplied list of paths.

It would be great if this functionality could be added to vscode-duktape-debug. Or maybe just strip the path, and search recursively under "localRoot"

Right now, I have had to modify duktape to push the filename only which then works correctly with the debugger

[harold-b]

Multiple search paths + a smarter file matching would be a useful feature. When I have some time to squeeze in I'll see about adding it :+1:

As a heads up, please note that support for duktape version < 2.0.0 will be phased out after the next release. The next version will support both 1.5.0/1.6.0 and 2.0.0, but will default to the 2.0.0 protocol by (you have to use type: "duk@1.5.0" to target that protocol). v2.0.0 does not support file-based APIs so duk_peval_file() has been dropped. (In case you plan on updating to v2.0.0).

[harold-b]

Actually, after writing this, I think I can make it so the user doesn't have to specify the target version explicitly. So perhaps no changes will be needed on the user side to target v1.5.0.

[willi1s]

I've not moved to v2.0.0 for two reasons. Firstly it is new out, and I prefer to wait a while before taking a new major release, I'll likely wait for v2.0.1. Secondly, I don't want to loose the support of this debugger, hence I'll also wait for your next major release.

You should be able to work out the protocol version without configuration as it is returned from the target upon connection. If you can support both old and new in the short term, that would be great as it would allow some overlap during the migration period.

If the file api has been dropped in v2.0.0 (I assume this is due to keeping duktape platform independent) I'll look at migrating my code in preparation for the upgrade.

[harold-b]

Yes, version >= 1.5. support will remain in the debugger for an indefinite period of time, what I meant is that I probably won't be providing much fixes for it as I focus more on v2. :) But we'll see, hopefully it is sufficiently stable now.

I am able to get the version automatically from the target, the problem is VSCode's debugger front-end dispatches events in a manner that make it a bit difficult to do that in the current way the code is written. So it will just take a bit more refactoring. Not a problem, I'm just extremely pressed for time with a current project so it will take a bit longer.

[andrewrch]

I added an option dukRemoteRoot which is a prefix on the environment being debugged. This is useful in my own project where the paths sent to duktape have a different directory structure to the folder structure in my project directory.

e.g.

my launch.json looks like:

{
    "name": "Attach (duk)",
    "type": "duk",
    "request": "attach",
    "address": "localhost",
    "port": 9091,
    "localRoots": [
        "${workspaceFolder}"
    ],
    "sourceMaps": true,
    "dukRemoteRoot": "some/path/on/remote/device",
    "outDir": "${workspaceFolder}/dist",
    "stopOnEntry": false,
    "debugLog": false
}

dukRemoteRoot is stripped from the paths that duktape passes to the debugger, and then appended again before setting breakpoints etc.

Does this sound like it would fit your use case?