Automate JS->JS dependencies

[sbc100]

While working on #19097 I had an idea on how to automate JS->JS dependencies. Similiar to what I did for __sig attributes in #19028.

The basic idea is that rather than manual specifying __deps for a given JS function we could use acorn to tokenize it and then figure out which other JS symbols it depends on.

This dependency extraction process could either be done eagerly at the same time that we extract the JS symbol list prior to calling wasm-ld, or it would be done lazily, on-demand, such that we would only need to tokenize function that we actually use.

Obviously we wouldn't want to slow down the linking process too much so we would need to measure the impact.

Either way the result would be that almost all the __deps entries could be removed and we would end up with cleaner and easier to maintain JS codebase, with fewer dependency bugs.

If it works very well we might even be able to completely remove the need to explicit deps, but that would be stretch goal.

[sbc100]

@dschuff @kripken @juj WDYT?

[juj]

we could use acorn to tokenize it and then figure out which other JS symbols it depends on.

I've also been thinking about this on several occassions.. "shouldn't we have enough correct context in correct namespace so that we would be able to 100% accurately build the JS deps automatically?"

But given the highly dynamic nature of JS, I am not completely sure if that will be the case. A prototype research around this area to gain more info what kind of things we might miss, or cause problems, would be awesome to read.

I think we'd have to rely on Closure's extern lists quite heavily. The problem will likely not be to get the JS deps, but the issue that we'd get too many deps, and then we'd need to silently ignore excess ones, that might become brittle.

If we did this, and it was not 100% precise, maybe we'd be able to compartmentalize the special cases to some known categories, and/or behave in a way that still manually specifying a __deps: [] list would allow one to override the automatic analysis with a manual one(?)

In general would be nice to see how well this kind of thing would work out.

[kripken]

This could be very useful - it is definitely annoying and error-prone to add the manual deps - but I agree with @juj that there is a risk of getting too many deps due to false positives (local shadowing etc), and those would silently be included.

Maybe an option is to have a tool that finds missing or unneeded deps, which we'd run and apply manually?