Open bruce-c-liu opened 5 days ago
IMO this makes sense. These third party tools and compiling the code before running it.
You can use node's experimental native typescript support instead?
@RafaelGSS for vis.
@RedYetiDev I understand, but I still need this functionality for debugging/logging purposes when using things like tsx
/ts-node
.
Seeing as how my custom function is able to achieve that, I assume there must be some way for util.getCallSite()
to support it as well?
You can use node's experimental native typescript support instead?
I'd like to hold off on that until it's non-experimental.
IMO it's not Node.js's responsibility to account for the compilation of third party tools before the code is even executed, that should be on them
Even more so, the call site (IIUC) is gotten from V8 under the hood, so there's not really a reliable way to translate that into the values before compilation
IMO it's not Node.js's responsibility to account for the compilation of third party tools before the code is even executed, that should be on them
Even more so, the call site (IIUC) is gotten from V8 under the hood, so there's not really a reliable way to translate that into the values before compilation
But there is a sourcemap that is supported natively in node js, so if ts-node / tsx generates sourcemap and the option is enabled in node, it should show the right line number, am I wrong?
True, that doesn't occur. @bruce-c-liu is that what you are describing, getCallSite
not respecting --enable-source-maps
?
Correct. I'm not well-versed in the technical details, but it seems like tools like tsx
do turn on source maps?
https://github.com/privatenumber/tsx/blob/master/src/source-map.ts
What is the problem this feature will solve?
Lot of people use tools like
ts-node
ortsx
when developing locally or even in production. The newutil.getCallSite()
function doesn't seem to report the line number from the original typescript file. Rather, it reports the transformed version of the file (e.g. bytsx
) with types stripped out/minified/etc?Example
expected:
line 20, col 12
received:line 1, col 15123
What is the feature you are proposing to solve the problem?
Have
util.getCallSite()
report original line number for TS files.What alternatives have you considered?
I currently have a custom function that does report the correct line number for the original typescript file. However, I would like to use the Node version if possible so I don't have to maintain this.