Incompatible with node-tap sourcemap support

[IlyaSemenov]

Bug description

I run node-tap tests with tsx as the loader.

I expect the stack trace reports to properly show the failing lines.

Instead, it always shows line 2 as the source of the error, regardless of how large the test file is.

When I replace tsx loader with @swc-node/register, everything works fine. I don't think node-tap has some inner hacks specifically tailored to @swc-node/register, it's more probable that tsx doesn't communicate with the tooling in some generally assumable way (whatever it be).

Reproduction

In an empty folder:

pnpm add tap tsx typescript @swc/core @swc-node/register

Create test.ts:

import tap from "tap"

tap.same("a", "a")

tap.same("a", "b")

Run pnpm tap --no-coverage --node-arg '--loader' --node-arg 'tsx' test.ts, you will get:

 FAIL  test.ts
 ✖ should be equivalent

  test.ts
  1 | import tap from "tap"
> 2 |
  3 | tap.same("a", "a")
  4 |
  5 | tap.same("a", "b")

Run pnpm tap --no-coverage --node-arg '-r' --node-arg '@swc-node/register' test.ts, you will get:

 FAIL  test.ts
 ✖ should be equivalent

  test.ts
  3 | tap.same("a", "a")
  4 |
> 5 | tap.same("a", "b")
    | ----^

Environment

System:
    OS: macOS 13.0.1
    CPU: (8) arm64 Apple M1
    Memory: 100.14 MB / 16.00 GB
    Shell: 5.8.1 - /bin/zsh
  Binaries:
    Node: 18.12.1 - ~/.nodenv/versions/18.12.1/bin/node
    npm: 8.19.2 - ~/.nodenv/versions/18.12.1/bin/npm
  npmPackages:
    tsx: ~3.12.1 => 3.12.1

Can you contribute a fix?

• [ ] I’m interested in opening a pull request for this issue.

[privatenumber]

As the issue template says, for reproductions that have dependencies or more than a code-snippet, you'll have to provide a link to a reproduction repository.

Since this issue is currently unverifiable, I'm going to close it. Please understand, there are many issues with inadequate reproductions that end up being an unrelated issue or expected behavior. I cannot afford to spend time re-recreating and debugging a reproduction that may potentially not be an issue.

Happy to re-open once a repro is provided so the issue is easily verifiable and debuggable.

[IlyaSemenov]

Reproduction repo https://github.com/IlyaSemenov/esbuild-kit-repro-170

[privatenumber]

Looked into this and there's no tsx bug.

With the version you had in your reproduction

tap --no-coverage --node-arg '--require=@esbuild-kit/cjs-loader' test.ts

With the latest tsx:

tap --no-coverage --node-arg '--require=tsx/cjs' test.ts