Description
What is the problem this feature will solve?
Hi,
I use Typescript, so I also use the --enable-source-maps
flag for node, in order to debug easily the issues.
But actually, sometimes it is better to have stack traces without the source maps, inside the same code.
For example, if trying to get the module name, to pass it maybe to Worker()
constructor, then it must be the transpiled JavaScript (and not the source TS).
There are methods to get the same info, but they are module-system dependent.
For example, __filename
for CommonJS, and fileURLToPath(import.meta.url)
for ESM, but their are not portable between module systems. So parsing the stack trace is the most portable way to get the actual current module.
Other uses can be when we are debugging code managed by a bundler/optimizer, it could be interesting to inspect also the actual stack trace (non source mapped). This is also important when there are "strange/unexpected behaviors" because the tsc
program performs something not so expected (so we like to inspect also the actual JavaScript code).
Regards
What is the feature you are proposing to solve the problem?
It could be nice to be able to get the preferred trace format and module name programmatically, so that in the same program, we could be in a function to have the stack trace with source maps, and in another function without source mappings, just by passing an option.
What alternatives have you considered?
I checked module-system dependent options, but:
- They are module system dependent
- I have found no way to get a complete stack trace with/without source map programmatically
I also checked Node docs, but I have found none to solve this issue:
Error.prepareStackTrace
: it already gets the source mapped stack trace infos