The source-phase alignment will be implemented in #4850.

As we bring all targets into alignment, the differences between their glue code will diminish.

I will open a dedicated discussion to explore how to unify the glue code across targets — this will reduce duplication and improve maintainability.

I will open a dedicated discussion to explore how to unify the glue code across targets — this will reduce duplication and improve maintainability.

Thanks, my point here is that we have two kinds of designs in play - the old "wasm sandwich" model with the bg file, which is good for instance outputs for bundlers that support tree-shaking of Wasm, and then the more modern instantiation models using source phase that are single file but don't require separate JS files and can have one JS file, and then dynamic instnatiation models which can align with this source phase model.

That is, it is only when using import { foo } from './foo.wasm' style instance integration that we need the "bg" file as separate. In all other cases it should be possibly to unify programmatic instantiation on the single JS file approach, where the source phase is the canonical example of that, and all other dynamic instantiations are effectively "polyfills of the source phase".

So my preference would be unifying on the source phase output model, but then retaining the "bg" model in the direct Wasm instance phase cases only.

Let me know if that makes sense?

Thanks for the clarification — I should have explained my original intention more clearly. I was actually planning to change the source phase output to use a separate _bg.js file as well. My main reason was maintainability: since the _bg.js logic is identical across output types, separating it out makes the code easier to reuse and refactor in the future. The differences between outputs would then only be in how the WebAssembly module is loaded.

That said, I completely understand and agree with your point—having multiple files adds extra network requests or file reads, so prioritizing performance over maintainability makes sense.

Could you confirm whether this is the design direction the wasm-bindgen team has chosen? If so, I’ll be happy to adjust this PR back to the single-file model.

Yes, exactly, thats the way we need to do it rather to only have bg for the direct Wasm instance phase output cases, and not otherwise, as we must prioritise output simplicity first and foremost.

This looks good to land to me, we just need to update the PR description and add a changelog entry.

Done.