Comment by turtleyacht
2 months ago
For reducing external dependencies, it would be nice to somehow know every call made to a package, generating the call tree to replace. That becomes the API of the internal, replacement package.
2 months ago
For reducing external dependencies, it would be nice to somehow know every call made to a package, generating the call tree to replace. That becomes the API of the internal, replacement package.
You mean this: https://npmgraph.js.org
Thank-you, that looks pretty useful. Prior attempts involved `git blame' in projects' package.json per package. For example, to find when a project adopted React x+1 in which version, to determine the next minimum upgrade (to React ^x.y).
Consuming a package also means following its development alongside one's own. Multiplied by each dependency, it's a commitment to a particular constellation of dependencies. Migration guides and codemods help, but ultimately maintenance requires active participation.
That takes time--often more than what's available.
Not sure that's possible with JS.
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.
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.
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