Assertions yield incorrect message when source is transpiled by loader

Version

v24.5.0

Platform

Linux dasprid-desktop 6.12.10-76061203-generic #202412060638~1753385872~22.04~dc2e00d SMP PREEMPT_DYNAMIC Thu J x86_64 x86_64 x86_64 GNU/Linux

Subsystem

internal/assert

What steps will reproduce the bug?

Create a test file in TypeScript with a test and an assertion in it:

import assert from "node:assert/strict";
import { it } from "node:test";

it("line issue", () => {
    assert.ok(false);
});

Running it through node test (through internal type stripping) will yield the correct result:

  AssertionError [ERR_ASSERTION]: The expression evaluated to a falsy value:
  
    assert.ok(false)

Running it with a loader like tsx will incorrectly identify the assertion source:

  AssertionError [ERR_ASSERTION]: The expression evaluated to a falsy value:
  
    it("line issue", () => {
    assert.ok(false);
    })

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

Reproduces every time.

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

Running through a TS loader should yield the same result as node with type stripping.

What do you see instead?

Assertion reports wrong source location.

Additional information

Previous finding can be found here: privatenumber/tsx#732

To summarize:

To generate the assertion message, Node.js captures a stack trace in its interal getErrMessage(). That stack trace references the transpiled location though; in this case, line 0, column 74.
It then loads the active file from disk (so test.ts). For line 0 it has a special handling in getCode(), where it will use findColumn() directly. Note that the column is the absolute column value, so a line break is simply considered a character in this case.
The parser then uses acorn internally to parse the TypeScript source. This search will most of the time yield partially or completely wrong results.

tsx (through esbuild) does include a source map in the transpiled code. I'm not sure how Node.js could handle this best. Ideally it'd scan the transpiled code to find the assertion source and then reference the original file through the source map.

But looking at the current code which always loads the executed file from disk, I'm not sure if Node.js even has access to the executed code at runtime.

I'm not sure I understand what's the issue you are reporting. If I run your example as a javascript file I get:

marcoippolito@Mac test % node --test test.js
✖ line issue (5.622834ms)
ℹ tests 1
ℹ suites 0
ℹ pass 0
ℹ fail 1
ℹ cancelled 0
ℹ skipped 0
ℹ todo 0
ℹ duration_ms 45.457291

✖ failing tests:

test at test.js:4:1
✖ line issue (5.622834ms)
  AssertionError [ERR_ASSERTION]: The expression evaluated to a falsy value:
  
    assert.ok(false)
  
      at TestContext.<anonymous> (file:///Users/marcoippolito/Documents/projects/test/test.js:5:12)
      at Test.runInAsyncScope (node:async_hooks:214:14)
      at Test.run (node:internal/test_runner/test:1081:25)
      at Test.start (node:internal/test_runner/test:978:17)
      at startSubtestAfterBootstrap (node:internal/test_runner/harness:332:17) {
    generatedMessage: true,
    code: 'ERR_ASSERTION',
    actual: false,
    expected: true,
    operator: '==',
    diff: 'simple'
  }

If I run it as a .ts:

marcoippolito@Mac test % node --test test.ts
✖ line issue (5.624459ms)
ℹ tests 1
ℹ suites 0
ℹ pass 0
ℹ fail 1
ℹ cancelled 0
ℹ skipped 0
ℹ todo 0
ℹ duration_ms 79.625875

✖ failing tests:

test at test.ts:4:1
✖ line issue (5.624459ms)
  AssertionError [ERR_ASSERTION]: The expression evaluated to a falsy value:
  
    assert.ok(false)
  
      at TestContext.<anonymous> (file:///Users/marcoippolito/Documents/projects/test/test.ts:5:12)
      at Test.runInAsyncScope (node:async_hooks:214:14)
      at Test.run (node:internal/test_runner/test:1081:25)
      at Test.start (node:internal/test_runner/test:978:17)
      at startSubtestAfterBootstrap (node:internal/test_runner/harness:332:17) {
    generatedMessage: true,
    code: 'ERR_ASSERTION',
    actual: false,
    expected: true,
    operator: '==',
    diff: 'simple'
  }

They are identical, so not sure how this is related to type stripping.
The stacktrace is correct and so is the line throwing the error. TSX can include more lines into the stacktrace that's up to the library

When referring to tsx, I'm talking about the https://github.com/privatenumber/tsx, not the file extension.

And yes, as I pointed out, when running the TypeScript file through Node directly, it produces the correct result. The issue is with loaders, so when you run it with tsx --test test.ts.

Well then you should open an issue to the tsx project repo, not node

As I mentioned in my description, I did open an issue with tsx, but after investigating the issue further, I saw the issue on the Node.js side, not solvable by loaders like tsx.

This is due to the fact that Node.js uses a stack trace from the transpiled code to get the location of the assertion, but then uses that location to scan the original source code from disk for the assertion code, instead of using the transpiled code.

Here's a minimal reproduction case:

loader.mts:

import fs from 'fs';
import { pathToFileURL } from 'url';

export async function load(url, context, defaultLoad) {
  const { format } = context;
  if (format === 'module') {
    let source = await fs.promises.readFile(new URL(url), 'utf8');
    source = `// Transformed\n\n${source}`;
    return { format: context.format, source, shortCircuit: true };
  }
  return defaultLoad(url, context, defaultLoad);
}

test.mts:

import assert from 'node:assert/strict';
import { test } from 'node:test';

test('falsy assertion', () => {
  assert.ok(false);
});

Running node --test test.mjs will correctly identify the assertion.

Running node --loader ./loader.mjs --test test.mjs on the other hand will fail to identify the assertion, as it is not taking the transpiled code into account.

I think the issue boils down to this:

node/lib/internal/assert/utils.js

Lines 165 to 174 in ab6991f

    
           const err = {}; 
        
           ErrorCaptureStackTrace(err, fn); 
        
           if (errorStackTraceLimitIsWritable) Error.stackTraceLimit = tmpLimit; 
        
           overrideStackTrace.set(err, (_, stack) => stack); 
        
           const call = err.stack[0]; 
        
           let filename = call.getFileName(); 
        
           const line = call.getLineNumber() - 1; 
        
           let column = call.getColumnNumber() - 1;

The ErrorCaptureStackTrace primordial seems to ignore any source map (according to the debugger), even with --enable-source-maps. This results in the wrong location and thus the wrong assertion lookup.

The reproduction in #59612 (comment) is not a correct example. Manipulating the source code without source maps is deemed to mess up with the mapped stack trace.

I can add a source map into the example, though ErrorCaputreStackTrace in that position does not respect the source map for some reason. I'll look into updating the example later tonight.

Okay, I've worked out a minimal reproduction case with source maps included:

test.mts:

import assert from 'node:assert/strict';
import { test } from 'node:test';

type Foo = {
    bar: string;
    baz: string;
};

test('falsy assertion', () => {
  assert.ok(false);
});

transformed.mjs (generated via esbuild):

import assert from "node:assert/strict";
import { test } from "node:test";
test("falsy assertion", () => {
  assert.ok(false);
});
//# sourceMappingURL=data:application/json;base64,ewogICJ2ZXJzaW9uIjogMywKICAic291cmNlcyI6IFsidGVzdC5tdHMiXSwKICAic291cmNlc0NvbnRlbnQiOiBbImltcG9ydCBhc3NlcnQgZnJvbSAnbm9kZTphc3NlcnQvc3RyaWN0JztcbmltcG9ydCB7IHRlc3QgfSBmcm9tICdub2RlOnRlc3QnO1xuXG50eXBlIEZvbyA9IHtcbiAgICBiYXI6IHN0cmluZztcbiAgICBiYXo6IHN0cmluZztcbn07XG5cbnRlc3QoJ2ZhbHN5IGFzc2VydGlvbicsICgpID0+IHtcbiAgYXNzZXJ0Lm9rKGZhbHNlKTtcbn0pO1xuIl0sCiAgIm1hcHBpbmdzIjogIkFBQUEsT0FBTyxZQUFZO0FBQ25CLFNBQVMsWUFBWTtBQU9yQixLQUFLLG1CQUFtQixNQUFNO0FBQzVCLFNBQU8sR0FBRyxLQUFLO0FBQ2pCLENBQUM7IiwKICAibmFtZXMiOiBbXQp9Cg==

loader.mjs:

import fs from 'fs';
import { pathToFileURL } from 'url';

export async function load(url, context, defaultLoad) {
  if (context.format !== 'module-typescript') {
    return defaultLoad(url, context, defaultLoad);
  }
  
  const transformed = await fs.promises.readFile(new URL("./transformed.mjs", import.meta.url), 'utf8');

  return {
    format: "module",
    source: transformed,
    shortCircuit: true,
  };
}

Run via the following command:

node --enable-source-maps --loader ./loader.mjs --test test.mts

This will yield the following failed test result:

test at test.mts:9:1
✖ falsy assertion (7.420299ms)
  AssertionError [ERR_ASSERTION]: false == true

We can see that the source map is correctly considered for the test location (line 9), but the assertion is incorrectly determined.

Running the test.mts through node without a loader (node --test test.mts) yields the correct assertion:

test at test.mts:9:1
✖ falsy assertion (3.305655ms)
  AssertionError [ERR_ASSERTION]: The expression evaluated to a falsy value:
  
    assert.ok(false)

Fixed in #59751.

Navigation Menu

Repository navigation

Assertions yield incorrect message when source is transpiled by loader #59612

Version

Platform

Subsystem

What steps will reproduce the bug?

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

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

What do you see instead?

Additional information

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	const err = {};
	ErrorCaptureStackTrace(err, fn);
	if (errorStackTraceLimitIsWritable) Error.stackTraceLimit = tmpLimit;

	overrideStackTrace.set(err, (_, stack) => stack);
	const call = err.stack[0];

	let filename = call.getFileName();
	const line = call.getLineNumber() - 1;
	let column = call.getColumnNumber() - 1;

Assertions yield incorrect message when source is transpiled by loader #59612

Description

Version

Platform

Subsystem

What steps will reproduce the bug?

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

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

What do you see instead?

Additional information

Activity

marco-ippolito commented on Aug 25, 2025

DASPRiD commented on Aug 25, 2025

DASPRiD commented on Aug 25, 2025

marco-ippolito commented on Aug 25, 2025

DASPRiD commented on Aug 25, 2025

DASPRiD commented on Aug 25, 2025

DASPRiD commented on Aug 26, 2025

legendecas commented on Aug 27, 2025

DASPRiD commented on Aug 27, 2025

DASPRiD commented on Aug 27, 2025

legendecas commented on Sep 11, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions