Cannot set snapshot with ts-node

[geekflyer]

I spent hours of try and error and simply can't get cloud debug agent to work with ts-node, not even with the simplest of all apps.
Below is an extremely simple app to reproduce the issue.

Environment details

• OS: OS X 10.13.6 High Sierra
• Node.js version: v10.15.3 (tried also with various lower 10.x versions and node 8.14.1)
• npm version: 6.4.1
• @google-cloud/debug-agent version: 3.0.1 (tried also 2.6.0)
• ts-node version: 8.0.3 (tried also 7.0.1 and 6.x.x)

Steps to reproduce

Run the following commands to setup a demo project to reproduce the error:

Prerequisites:

• assumes you have locally ADC credentials for an cloud debugger enabled gcp project ( gcloud auth application-default login)

Steps:
Prepare reproduction using https://github.com/geekflyer/google-cloud-debugger-bug-repro :

git clone [email protected]:geekflyer/google-cloud-debugger-bug-repro.git && cd google-cloud-debugger-bug-repro
npm install
gcloud debug source gen-repo-info-file 

1. Run code as simple JS app via PROJECT=<gcp_project> npm run jsapp and set a watchpoint on the line const foo = Math.random(); in file src/jsapp.js and observe that the snapshot gets hit. It works as expected.

2. Run code as typescript app via PROJECT=<gcp_project> npm run tsapp and set a watchpoint in the line const foo = Math.random(); in file src/jsapp.ts and observe the following ERROR:

The app prints:

@google-cloud/debug-agent Error: Unable to clear breakpoint in v8
    at Object.setErrorStatusAndCallback (/Users/christian/dev/cloud-debugger-test/node_modules/@google-cloud/debug-agent/build/src/agent/util/utils.js:158:19)
    at InspectorDebugApi.clear (/Users/christian/dev/cloud-debugger-test/node_modules/@google-cloud/debug-agent/build/src/agent/v8/inspector-debugapi.js:113:26)
    at Debuglet.removeBreakpoint_ (/Users/christian/dev/cloud-debugger-test/node_modules/@google-cloud/debug-agent/build/src/agent/debuglet.js:651:26)
    at that.controller.updateBreakpoint (/Users/christian/dev/cloud-debugger-test/node_modules/@google-cloud/debug-agent/build/src/agent/debuglet.js:734:22)
    at request (/Users/christian/dev/cloud-debugger-test/node_modules/@google-cloud/debug-agent/build/src/agent/controller.js:135:17)
    at request_.then.res (/Users/christian/dev/cloud-debugger-test/node_modules/@google-cloud/common/build/src/service-object.js:236:44)
    at process._tickCallback (internal/process/next_tick.js:68:7)

AND cloud debug never hits the snapshot AND after a while Cloud Debug displays Could not determine the output file associated with the transpiled input file.

The error message seems similar to #401, however I can consistently reproduce the error and I tried a dozen of other versions / library combinations and couldn't get to work any ts-node based application.
Note I also once included require('source-map-support/register'); which didn't help either.

In short: It seems impossible to use cloud debug with ts-node.

Thanks for fixing in advance!

[DominicKramer]

Thanks for letting us know about this. I suspect what is happening is that ts-node does not generate .js or sourcemap files to disk. However, when a watchpoint is set in a .ts file, the debug agent looks for the associated sourcemap file to instruct V8 where to set the snapshot in the associated .js file.

Since ts-node does not create these files on disk, this process does not work and the debug agent cannot set the snapshot.

Our next steps will be to investigate how (if possible) we can access ts-node's in-memory source maps and instruct V8 how to set the snapshot.

In the meantime, a workaround would be to transpile the typescript to javascript with source-maps.

[ofrobots]

Using ts-node in production is not a popular use-case. I fear that depending on in-memory source-maps from ts-node may be quite brittle.

@geekflyer is there a reason you cannot use transpiled source code?

[geekflyer]

Who says that using ts-node in production is not a popular use case? Tbh that's what we do since 2 years with multiple apps and we never encountered any problem with that. In fact it simplifies the build / deploy process quite a lot. The runtime overhead (slightly slower bootstrap) in conjunction with the --transpile-only flag is almost unnoticeable.
Looking in the web we don't seem to be alone with using ts-node in production:
https://www.reddit.com/r/typescript/comments/8vkvzy/typescript_with_node_should_i_use_tsnode_or_tsc/

[geekflyer]

Btw, it is my understanding that ts-node actually creates source-maps on disk in a temporary cache directory.

[ofrobots]

@geekflyer my intention wasn't to say that no one deploys that way, or that it is not a valid way to deploy! On the contrary, if you find your self productive with this setup, that's awesome.

I do think that this is a feature request and we have to evaluate against our other priorities, and the frequency/popularity of the use-case matters.

[DominicKramer]

I've investigated this and ts-node no longer appears to store sourcemaps in a temporary directory. Further, I don't see a way to access ts-nodes's in-memory sourcemaps. Because of that, we are not able to implement this feature request, and I am going to close this issue. If there is needs by others for this feature, please let us know.

[geekflyer]

@ofrobots @DominicKramer Would you consider reopening this issue?
There's some discussion under TypeStrong/ts-node#807 (comment) . Apparently it should be possible to get the source maps of ts-node via source-map-resolve.

[abinici]

Is this still an issue? Because I am planning to use ts-node in production, because ts-node simplifies the node runtime when using TypeScript.

[DominicKramer]

As far as I know, this is still an issue, but it may be addressed as a side effect of the work in PR #837.