Cannot access source-maps

[geekflyer]

Hi,

I'd like to use ts-node in conjunction with Google Cloud Debugger.
The folks from Google are saying that they can't support ts-node because it doesn't expose the source-maps (googleapis/cloud-debug-nodejs#652 (comment) ).

Any thoughts on if and how this dilemma can be solved?

Thanks!

[blakeembrey]

@geekflyer I can think of some workarounds that would be relatively easy. Either via source-map-support since the source maps are registered there or by exposing the package either globally or a locally via a singleton. E.g. require('ts-node').registered.sourceMaps. Who's the best person over there to help come up with an adequate solution?

[geekflyer]

I don't work for Google, so the only information I have is from googleapis/cloud-debug-nodejs#652 (comment) and https://github.com/googleapis/cloud-debug-nodejs/graphs/contributors and it looks like @ofrobots and @DominicKramer would be the best persons to talk to.

[geekflyer]

btw i faced the same problem a while ago with https://www.rookout.com . So maybe one of them ( @itielshwartz @LiranLast @orishavit @orweis @tkore ) wants to chime in for a solution as well.

Would be cool if we can solve this for both rookout and cloud debugger.

[LiranLast]

@geekflyer - Rookout does support debugging ts-node if you configure typescript to build source maps. The easiest way of doing that is using the tsconfig.js file - it may or may not work with Google Cloud Debugger as well.

If you are interested, I would love to hear more about what you are trying to achieve using Rookout/Google Cloud Debugger.

[geekflyer]

Hey @LiranLast thanks for your response. Are you sure this is working with ts-node? I tried out rookout with ts-node in November last year and didn't get it to work. Quite possible that things might have changed for good in the meantime though or that the root cause was another one. Is there a minimal example using ts-node with rookout somewhere? Thanks

[LiranLast]

Hi @geekflyer check out this link. @Zohar2506 tested it with ts-node earlier today.

Feel free to reach out using the in-app chat or any other way.

[blakeembrey]

FWIW, ts-node always builds source maps so it shouldn’t require configuration. How does Rookout work/use these source maps?

[LiranLast]

@blakeembrey you may be right, we just used our standard TypeScript configuration. I definitely think building source maps by default is the way to go.

Internally, Rookout uses source-map-resolve to get source map information.

[bcoe]

👋 I've been working on adding support for source-maps into Node.js itself, --enable-source-maps in [email protected] works similarly to --source-map-support.

One thought on my mind, is whether we could expose a public API that lets implementors look at what source-maps have been cached in Node.js itself.

In general, would love help kicking the tires of this new feature.

[LiranLast]

@bcoe this sounds like an amazing feature.

We are currently relying on the inspector API together with a few third-party libraries to load the source maps. Built-in support would help us a lot, and we would love to take part in this feature!

[bcoe]

@LiranLast awesome, would love the help from some folks who have specific use-cases (beyond my own 😄 ). I've created a tracking issue here:

nodejs/node#29865

And am happy to help folks onboard to the Node.js project who'd like to pitch in.

[cspotcode]

@bcoe I'm taking a quick look at this, and I'm not sure if anything is required from ts-node to support node's native sourcemap reader.

We install require('source-map-support') and give it access to our in-memory cache of compiled files:

ts-node/src/index.ts

Lines 464 to 479 in ce7c323

	sourceMapSupport.install({
	environment: 'node',
	retrieveFile (pathOrUrl: string) {
	let path = pathOrUrl
	// If it's a file URL, convert to local path
	// Note: fileURLToPath does not exist on early node v10
	// I could not find a way to handle non-URLs except to swallow an error
	if (options.experimentalEsmLoader && path.startsWith('file://')) {
	try {
	path = fileURLToPath(path)
	} catch (e) {/* swallow error */}
	}
	path = normalizeSlashes(path)
	return outputCache.get(path)?.content || ''
	}
	})

Each emitted file has the sourcemap embedded as base64, so there is no need to read an extra .map file.

ts-node/src/index.ts

Lines 1038 to 1047 in ce7c323

	/**
	* Update the output remapping the source map.
	*/
	function updateOutput (outputText: string, fileName: string, sourceMap: string, getExtension: (fileName: string) => string) {
	const base64Map = Buffer.from(updateSourceMap(sourceMap, fileName), 'utf8').toString('base64')
	const sourceMapContent = `data:application/json;charset=utf-8;base64,${base64Map}`
	const sourceMapLength = `${basename(fileName)}.map`.length + (getExtension(fileName).length - extname(fileName).length)
	return outputText.slice(0, -sourceMapLength) + sourceMapContent
	}

Do we need to do anything extra for --enable-source-maps?

One quirk: the filenames are the original .ts filenames, matching the filesystem, but our in-memory cache contains the emitted JS output. If node tries to read the files from disk, it will not find the sourcemap. It must read what we pass to module._compile(), or else we need to somehow tell it how to use our in-memory cache.