[cj]

You could theoretically overwrite the public functions of a module, inject some logging code, then execute the originally intended function when it's called with ".apply()" and passing the original arguments in.

That might get you part of the way there.

[turtleyacht]

Yes, some automated instrumentation equivalent of `debugger' at the start of the module's first such function, and stepping into each function down to some depth, then starting over with the next line of the module's implementation.

A partial or semi-automated, tool-assisted approach might be possible, if there were a way to restart Node.js between decisions. Each decision point writes an entry "event" that records the filename, function, caller, line number, etc. Then `debugger' is inserted before the next line, and so on.

[privatelypublic]

I'm thinking eval's and prototype overloading would make this a permanent cat and mouse game.

Frankly, I don't see how the node ecosystem can ever be secure. It's random-libraries all the way down. With half of them being useless frippery.

Imho, WASM compiled from languages that have strong standard libraries are the way forward for security. And, maybe node will get fixed in 5-10 years.

A good example of a language going "this shouldn't be a library."- Net used to only have a third party json parser (newtonsoft) but microsoft created a first party json parser and deprecated newtonsoft from their examples and templates