Line numbers in error stack not changing

[vladpazych]

In my code generator project, I watch directory and on each change do require.cache cleaning and rerequire modules from that directory.

And I use stack to implement one important feature.

var stack = new Error().stack;
var stackLines = stack.match(/[^\r\n]+/g);
console.log(stackLines[1]) 

>>>
at Object.<anonymous> (/Workspace/gener/data.js:1:13)

Rerequire works fine, because each time file changes, I see that console.log, meaning file is actually rerequired.

But if I move var stack = new Error().stack; down by 5 lines, I still get:

at Object.<anonymous> (/Workspace/gener/data.js:1:13) // I get
at Object.<anonymous> (/Workspace/gener/data.js:6:13) // I should get

If I do same experiment in pure js and node - it works fine.

So the only moving part between working version and not working version is node server.js and ts-node server.js

[blakeembrey]

Can you please share more information about your project? There's not much to go off here. Things like:

• What's your tsconfig.json file?
• Why are you running JavaScript files with ts-node?
• Are you using allowJs?
• Did you change any other code when you moved the line or did you just hit enter five times?

[vladpazych]

tsconfig.json:

{
    "compilerOptions": {
        "target": "es5",
        "module": "commonjs",
        "sourceMap": true,
        "noImplicitUseStrict": true,
        "noImplicitAny": false,
        "allowJs": true,
        "allowSyntheticDefaultImports": true
    }
}

---

I am running js file with ts-node to show that there is problem in ts-node and not in node in general.

---

I just hit enter five times.

---

My project is for generating code from typescript declarations.

class components {
    application = Component().Contexts(contexts.core)
}
```javascript
Then I generate C# code, using handlebars template. And I need component to know that it's name is application, without passing string to Component constructor.

---

I think there is some kind of cache of typescript files, and new Error().stack somehow accessing it instead of changed file.

[blakeembrey]

If there is a cache issue, it seems like it'd be coming from TypeScript and not ts-node, in this case. However, there's not enough to work off right now. If you can put together an example project, I can take a look, but no one else has reported a watch issue when clearing require.cache so I'm going to guess it's either related to your configuration (maybe the .js configuration - are you using the ts-node CLI or ts-node/register?) or a TypeScript internal cache because only whitespace has changed and nothing between the generated output would actually have changed. Can you share the entire stack?

[vladpazych]

Okay, tomorrow I will put together example project.

[blakeembrey]

Thanks, that'll be really helpful to me! I don't always have time to replicate the exact same scenarios so something I can quickly clone make my like 100x easier and faster to narrow down or fix any issues 👍

[vladpazych]

Here is the example project: https://github.com/vladpazych/ts-node-stack-problem-investigation.git

You will find instructions to replicate problem inside server.js file.

Thank you for support.

[renehamburger]

@blakeembrey, I'm experiencing a similar issue when running Protractor tests through ts-node. The line and column numbers of the stack traces of errors thrown in the test files themselves are never correct. This is tricky, of course, as test expectations fail frequently and having an accurate stack trace is crucial.

Here's a minimal example which allows you to reproduce this issue: https://github.com/renehamburger/ts-node-stack-problem.

This example shows, that the *.ts file executed through ts-node has wrong stack traces, whereas the *.js pre-compiled with tsc with source maps has correct stack traces.

I have not been able to reproduce this issue with simpler test cases, e.g. in a single TypeScript file. Usually the stack trace is absolutely accurate.

Is this more likely to be a source-map-support issue?

[renehamburger]

I discovered the culprit! Protractor activates it's own source-map-support, which probably conflicts with the one in ts-node. Adding a skipSourceMapSupport: true to Protractor's config resolves the issue completely!

I'll post an issue at source-map-support to either resolve this issue or log a warning when it's activated multiple times.

[richtera]

All of a sudden my lines are off on stacktraces again. I am passing the tsconfig.json using --project so sourceMap support is on and I am loading source-map-support anywhere I can see. I am not quite sure how to resolve the offsets?

[cspotcode]

I tracked this down to an issue with invalidating sourcemap cache in source-map-support. Without such an API, we can't tell source-map-support that it needs to fetch a new sourcemap from us.

See: evanw/node-source-map-support#281 where I have requested a cache invalidation API

[blakeembrey]

@cspotcode We might be able to specify emptyCacheBetweenOperations for now, it appears this would clear out the cache before each stack trace created.

[cspotcode]

@blakeembrey yeah, that could work. Do you know, are non-ts-node sourcemaps kept in that cache? Would wiping the cache lead to a bunch of extra FS calls for node_modules which bundle sourcemaps? I'm not 100% clear on if/when source-map-support pulls sourcemaps from disk without pulling from ts-node's retrieveFile() cache.

[blakeembrey]

@cspotcode I don't, but I assume yes and it could lead to some extra FS calls for other packages.

[BryanHunt]

Is this issue why I'm seeing my stack line numbers be wrong when running mocha tests with ts-node/register?

[mindplay-dk]

Is this issue why I'm seeing my stack line numbers be wrong when running mocha tests with ts-node/register?

Same question here.

Using something like this, I'm getting no meaningful file/line-numbers.