Test runner location output not source-mapped

[malthe]

Version

v21.3.0

Platform

Darwin wavel.local 23.2.0 Darwin Kernel Version 23.2.0: Wed Nov 15 21:53:34 PST 2023; root:xnu-10002.61.3~2/RELEASE_ARM64_T8103 arm64

Subsystem

node:test

What steps will reproduce the bug?

I have checked in a simple example at
https://github.com/malthe/node/tree/source-map-test-issue.

Clone the repo and run the following commands.

$ npm i -D ts-node
$ node --loader ts-node/esm --enable-source-maps test.mts

How often does it reproduce? Is there a required condition?

No response

What is the expected behavior? Why is that the expected behavior?

In the first line in the output, starting with "test at", notice that the location is being reported as "3:1".

But there is nothing on this line, it's empty. It should be "4:1". The "test at" location is not mapped, even though --enable-source-maps is given.

In the stack trace provided for the assertion failure, locations are correct (mapped).

Note that if this option is not used at all, then both locations are wrong (i.e., unmapped).

What do you see instead?

...
✖ failing tests:

test at file:/.../test.mts:3:1
✖ hello (1.201292ms)
  AssertionError [ERR_ASSERTION]: Expected values to be strictly equal:
  
  1 !== 2
  
      at TestContext.<anonymous> (file:///.../test.mts:5:10)
      at Test.runInAsyncScope (node:async_hooks:206:9)
      at Test.run (node:internal/test_runner/test:631:25)
      at Test.start (node:internal/test_runner/test:542:17)
      at startSubtest (node:internal/test_runner/harness:216:17) {
    generatedMessage: true,
    code: 'ERR_ASSERTION',
    actual: 1,
    expected: 2,
    operator: 'strictEqual'
  }

Additional information

No response

[MoLow]

My guess is this is not diredtly related to the test runner, do you have a minimal reproduction?

[malthe]

@MoLow that repo/branch linked ^^^ is an attempt at a minimal reproduction, but I don't know enough about how it works to take ts-node out of the equation.

Note that it is somewhat related to the test runner at least in the sense that it's the test runner output specifically that lacks correct location information.