[22.9.0] util.getCallSite() doesn't report original line number for TS files

[bruce-c-liu]

What is the problem this feature will solve?

Lot of people use tools like ts-node or tsx when developing locally or even in production. The new util.getCallSite() function doesn't seem to report the line number from the original typescript file. Rather, it reports the transformed version of the file (e.g. by tsx) with types stripped out/minified/etc?

Example

expected: line 20, col 12
received: line 1, col 15123

What is the feature you are proposing to solve the problem?

Have util.getCallSite() report original line number for TS files.

What alternatives have you considered?

I currently have a custom function that does report the correct line number for the original typescript file. However, I would like to use the Node version if possible so I don't have to maintain this.

const ORIGINAL_STACK_TRACE_LIMIT = Error.stackTraceLimit;

/**
 * Returns information about the indicated frame in the stack trace.
 * frameIndex = 0 corresponds to the function that calls stackedTrace().
 *
 * Below sample values assume frameIndex = 1.
 * Inspiration: https://www.npmjs.com/package/callsites/v/3.1.0
 */
export function stackTrace(frameIndex = 0) {
  // Optimization: Adjust stackTraceLimit to the minimum depth required to get the desired frameIndex.
  // This significantly reduces the depth of the produced stack trace. (Node 22's default limit is 10)
  Error.stackTraceLimit = frameIndex + 1;
  const error = { stack: "" };

  // https://nodejs.org/api/errors.html#errorcapturestacktracetargetobject-constructoropt
  // Creates a `.stack` property on provided object
  Error.captureStackTrace(
    error,
    stackTrace // don't include the stackTrace() function itself in the trace
  );
  Error.stackTraceLimit = ORIGINAL_STACK_TRACE_LIMIT; // restore original stackTraceLimit

  // "Error
  //   at DerivedLogger.logger.<computed> (/Users/bruce.liu/Desktop/ai-search/server/logging/logger.ts:50:20)
  //   at Server.<anonymous> (/Users/bruce.liu/Desktop/ai-search/server/index.ts:58:12)"
  const stackErrorMsg = error.stack;

  // [
  //   "at DerivedLogger.logger.<computed> (/Users/bruce.liu/Desktop/ai-search/server/logging/logger.ts:50:20)",
  //   "at Server.<anonymous> (/Users/bruce.liu/Desktop/ai-search/server/index.ts:58:12)"
  // ]
  const frames = stackErrorMsg.split("\n").slice(1);

  // "at Server.<anonymous> (/Users/bruce.liu/Desktop/ai-search/server/index.ts:58:12)"
  let frameOfInterest = frames[frameIndex]!;

  // "at Server.<anonymous> /Users/bruce.liu/Desktop/ai-search/server/index.ts:58:12"
  frameOfInterest = frameOfInterest.replace(/[()]/g, ""); // remove "(" and ")"

  // "/Users/bruce.liu/Desktop/ai-search/server/index.ts:58:12"
  frameOfInterest = frameOfInterest.split(" ").at(-1)!;

  return frameOfInterest;
}

[RedYetiDev]

IMO this makes sense. These third party tools and compiling the code before running it.

You can use node's experimental native typescript support instead?

[bruce-c-liu]

@RafaelGSS for vis.

@RedYetiDev I understand, but I still need this functionality for debugging/logging purposes when using things like tsx/ts-node.

Seeing as how my custom function is able to achieve that, I assume there must be some way for util.getCallSite() to support it as well?

You can use node's experimental native typescript support instead?

I'd like to hold off on that until it's non-experimental.

[RedYetiDev]

IMO it's not Node.js's responsibility to account for the compilation of third party tools before the code is even executed, that should be on them

Even more so, the call site (IIUC) is gotten from V8 under the hood, so there's not really a reliable way to translate that into the values before compilation

[artur-ma]

IMO it's not Node.js's responsibility to account for the compilation of third party tools before the code is even executed, that should be on them

Even more so, the call site (IIUC) is gotten from V8 under the hood, so there's not really a reliable way to translate that into the values before compilation

But there is a sourcemap that is supported natively in node js, so if ts-node / tsx generates sourcemap and the option is enabled in node, it should show the right line number, am I wrong?

[RedYetiDev]

True, that doesn't occur. @bruce-c-liu is that what you are describing, getCallSite not respecting --enable-source-maps?

[bruce-c-liu]

Correct. I'm not well-versed in the technical details, but it seems like tools like tsx do turn on source maps?
https://github.com/privatenumber/tsx/blob/master/src/source-map.ts

[alexanderniebuhr]

It even doesn't for with experimental TS support in node #55211

[joyeecheung]

It comes down to whether util.getCallSite() wants to reach feature parity with err.stack. err.stack is generated by Node.js's stack trace preparation handler, which will map the source positions using the source maps it read from disk; util.getCallSite() on the other hand only does a small subset of what the stack trace preparation handler does. Not sure if anyone or @RafaelGSS wants to work on taking care of the mapping in util.getCallSite() as well, or if we just want to keep the API to only handle the basics as it does now.