When exactly should `--post-js` code execute?

[sbc100]

In some cases the --post-js code executes on load, right after the JS library code is loaded.

In other cases (specifically in the -sMODULARIZE case today) the code doesn't run until have instantiation and after the main function has run.

We should probably pick one behavior and stick with it.

[sbc100]

I imagine that --pre-js and --post-js were originally just about where, positionally the code appears in the output file. i.e. before or after the generated code.

I don't imagine it was ever intended for the --post-js to to actually run after any of the user code is actually running. This is because we have preInit, postRun, etc callbacks for scheduling code to run at specific times like this. Is that right @kripken ?

So I guess I'm leaning towards always have post-js code execute first load, after the library JS code, but before any wasm module loading code is started.

[sbc100]

@kripken @juj @dschuff @brendandahl

[brendandahl]

Have we always run post-js after main in modularize? I have a feeling that may have changed when we started using await. I agree though, it seems post-js should run before any wasm, but after most the js has been defined so a user can override whatever they want to (whether that's a good idea is another topic).

[sbc100]

Yes, it was recently changed in and then made #23157 and then made more consistent in #23629.

I'm proposing we reverse this and always include --post-js code before any await

[juj]

I imagine that --pre-js and --post-js were originally just about where, positionally the code appears in the output file. i.e. before or after the generated code.

Yeah, agree, I think originally --post-js was placed so that it would go after the compiled JS (asm.js) code that fastcomp (LLVM) generated, but before the hand-written JS runtime code would launch main(). @kripken might remember best.

If I try to ponder what would be more useful, then I presume that having --post-js execute before main() would be more useful than having --post-js execute after main().

I'm proposing we reverse this and always include --post-js code before any await

So --post-js would execute not only before main(), but also before any asynchronous operations are resolved, e.g. async wasm instantiation or async fetch?

I suppose that would be "--post-js runs last in the synchronous parsing stage of the .js file, before asynchronous operations start and main() runs"?

To me that sounds good.

[kripken]

I imagine that --pre-js and --post-js were originally just about where, positionally the code appears in the output file. i.e. before or after the generated code.

Yes, and that was before we had async compilation etc., so things were much simpler.

The main use case for--post-js was to add things like manual JS bindings. Things that can be defined after the compiled code has been set up, and that the compiled code itself does not need to call.

[sbc100]

Things that can be defined after the compiled code has been set up, and that the compiled code itself does not need to call.

Can you say more about what you mean exactly by this? Does the native code need to be accessible at this point? I don't think it generally has been (at least not for a long time).

[kripken]

I think we did use this originally under the assumption that native code was accessible, yes. At least it could be referred to - exports existed (but were only wrappers, for async compilation).

But maybe that isn't necessary now, and yeah, maybe modes like modularize didn't support it.

It might be fine to not support post-js for modularize and other such modes. I honestly don't know if it is important in general, even. We do have --extern-post-js to help with basic code wrapping anyhow.

[sbc100]

We also have all of the preRun and postRun and addOnInit and addOnPreMain and addOnPostCtor things if you want to actually interact with code.

I feel like the --pre-js and --post-js code should all be executed at top level import time, and we should probably declare that non of the native code is ready at the time its executed. If you want to interact with the native code you need to install one of the delayed handlers above. Does that sounds reasonable? (IIUC his is what @juj was agreeing to above).

[kripken]

Sounds reasonable to me.