Wrong line number from Error.stack

[bchabrier]

Search Terms

stack, line number

Expected Behavior

Error stack should provide the exact line number where the error occurs

Actual Behavior

In some cases, the error stack provides a wrong line number

Steps to reproduce the problem

I have created a repo to reproduce the problem with the smallest setup I could: https://github.com/bchabrier/tsnodewronglinenumber

The test compiles the .ts file once with ts-node and once with tsc to show that with ts-node the error stack provides a wrong line number while using the .js file compiled by tsc the line number is correct.

Also, the test shows that it fails or succeeds depending on what module is imported behind...

Minimal reproduction

Clone https://github.com/bchabrier/tsnodewronglinenumber
Run sh ./run.sh

On my system is shows:

$  sh run.sh
==> Checking with zwave-js with tsc and ts-node on js file:
$ rm -fr dist; tsc; ts-node dist/err_check.js
node_modules/zwave-js/build/lib/node/Node.d.ts:21:22 - error TS2420: Class 'ZWaveNode' incorrectly implements interface 'SecurityClassOwner'.
  Property 'securityClasses' is missing in type 'ZWaveNode' but required in type 'SecurityClassOwner'.

21 export declare class ZWaveNode extends Endpoint implements SecurityClassOwner {
                        ~~~~~~~~~

  node_modules/@zwave-js/core/build/security/SecurityClass.d.ts:24:14
    24     readonly securityClasses: Map<SecurityClass, boolean>;
                    ~~~~~~~~~~~~~~~
    'securityClasses' is declared here.


Found 1 error.


Loading zwave-js
line number should be 7, is 7, OK                                   <=== works fine when compiled with tsc, despite transpilation shows some erros

==> Checking with zwave-js with ts-node:
$ ts-node err_check.ts

Loading zwave-js
line number should be 7, is 8, =====> KO <=====               <===== error, line number is wrong when using ts-node to compile

==> Checking with ts-md5 with tsc and ts-node on js file:
$ rm -fr dist; tsc; ts-node dist/err_check.js

Loading ts-md5
line number should be 7, is 7, OK                                  <=== works fine with another module...
==> Checking with ts-md5 with ts-node:
$ ts-node err_check.ts

Loading ts-md5
line number should be 7, is 7, OK                                  <=== works fine with another module...

Specifications

• ts-node version:
  ts-node v10.2.1
• node version:
  node v14.16.0
• TypeScript version:
  compiler v4.4.3
• tsconfig.json, if you're using one:

{
  "compilerOptions": {
    "noImplicitAny": true,
    "target": "es2017",
    "module": "commonjs",
    "sourceMap": true,
    "inlineSources": false,
    "rootDir": ".",
    "declaration": false,
    "outDir": "./dist",
    "types": [
      "node"
    ],
    "experimentalDecorators": true,
    "emitDecoratorMetadata": true,
    "esModuleInterop": true
  },
  "exclude": [
    "./dist",
    "./node_modules",
  ]
}

• Operating system and version:
  Linux raspberrypi 4.19.118-v7+ #1311 SMP Mon Apr 27 14:21:24 BST 2020 armv7l GNU/Linux
• If Windows, are you using WSL or WSL2?:

[cspotcode]

This is probably an issue with source-map-support and @cspotcode/source-map-support which will be fixed by #1496. I see that zwave-js depends on source-map-support.

For a list of reasons why we're using @cspotcode/source-map-support, there's a changelog here: cspotcode/node-source-map-support#24

[bchabrier]

Sounds similar and related, indeed...

Do you think there is a way for me to workaround this until 10.3.0 is released? For instance with something like node -r ts-node/register -r @cspotcode/source-map-support (unfortunately this one doesn't work, I just tried...)?

[cspotcode]

I just published 10.3.0 so this should be solved. If you hit problems, though, please let us know. We can always re-open this issue or you can file a new one.

https://github.com/TypeStrong/ts-node/releases/tag/v10.3.0

[bchabrier]

I confirm it's working fine now with v10.3.0.

Thanks a lot!

[sazzer]

I'm not sure but I think this is happening again with 10.9.1. (And likely earlier versions - I've not checked.) I've just raised a bug against pino-caller but on further searching it might be a recurrence of this bug instead. pino-caller uses Error().stack to get the file and line numbers to include in the log messages.

Cheers

[gthb]

I'm not sure but I think this is happening again with 10.9.1.

For me it seems to be clearly occurring only in Node v20 onwards, absent in Node v19 and earlier. @sazzer does that match your experience as well?

Opened a new issue with a clean repro: #2053

[sazzer]

I'd only noticed it in Node 20, but I've not tried in earlier versions so I'm not 100%.
It seems feasible though, since the way that this works changed notably in Node 20 I believe. (Certainly the way that you have to launch Node with it has changed...)