Repository navigation
Wrong line number from Error.stack #1495
Copy link
Copy link
Closed
Milestone
Description
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?:
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
No labels
Activity
cspotcode commentedon Oct 10, 2021
This is probably an issue with
source-map-supportand@cspotcode/source-map-supportwhich will be fixed by #1496. I see thatzwave-jsdepends onsource-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#24bchabrier commentedon Oct 11, 2021
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 commentedon Oct 11, 2021
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 commentedon Oct 11, 2021
I confirm it's working fine now with v10.3.0.
Thanks a lot!
sazzer commentedon Aug 6, 2023
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-callerusesError().stackto get the file and line numbers to include in the log messages.Cheers
gthb commentedon Sep 5, 2023
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 commentedon Sep 5, 2023
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...)