Untracable error messages from beyond short-circuitted load hooks

[blikest]

I've been quite lost for a few days not knowing where a SyntaxError was coming from in a module's import graph,
as I'm compiling typescript imports by returning {source:output,shortCircuit:true,format:"module"} from load,
and all I saw was

SyntaxError: Missing initializer in const declaration
    at ESMLoader.moduleStrategy (node:internal/modules/esm/translators:117:18)
    at ESMLoader.moduleProvider (node:internal/modules/esm/loader:460:14) 

thrown at the entry import of the typescript module graph.

I logged every compiled source code along with the specifier argument before the shortCircuit to spot which file's final modularization was throwing that syntax error.

Since there is no control over what happens beyond the load hook, would it be possible to simply disclose the specifiers in the error messages coming from there, or otherwise figure out a way to catch them somehow after emerging from load hooks with a shortCircuit?

The first one could be easy peasy, for the second the only solution i can imagine is exposing a "modularize" hook where one could customize the interpretation of the source code with the "vm" module. Which wouldn't be half bad in itself, but also one doesn't exclude the other either (more informative logging in the default modularization "hook", wether it ever gets exposed as "nextModularize" or not).

[aduh95]

What version of Node.js are you using?

[blikest]

@aduh95 21.1 now when i'm encountering it again.
i'm returning {source,format,shortCircuit} entries from the registered "load" hook for many files, and at some point all i see is:

node:internal/event_target:1084
  process.nextTick(() => { throw err; });
                           ^
SyntaxError [Error]: Unexpected reserved word
    at ModuleLoader.moduleStrategy (node:internal/modules/esm/translators:155:18)
    at callTranslator (node:internal/modules/esm/loader:285:14)
    at ModuleLoader.moduleProvider (node:internal/modules/esm/loader:291:30)

Node.js v21.1.0

without context.

A few files get passed forward to the default nextLoad,
and i can't even exclude that one of those throws this,
but i assume in that case the stack trace would report the location of the import due to the call to nextLoad being present in it.
But since a lot of files are being transpiled like this,
i am struggling to come up with a way to re-parse them before the shortCircuit to be able to reproduce the syntax error.
Whatever follows internally after the shortCircuit return, it seems to me that it could catch the parse error from moduleProvider and report something from (or at) the earlier stack along with it.

[blikest]

actually inserting a re-parse/serialization in the load hook to get usable stack trace wasn't a big issue and it solved my problem, but the fact that i have to parse each file an additional time only because there's no way to trace or catch errors from shortCircuits is what seems wasteful.