What is the intended way to disable import/export minification?

[kg]

MINIFY_WASM_EXPORT_NAMES and MINIFY_WASM_IMPORTS_AND_EXPORTS both exist as settings, but we're not allowed to actually use them. The logic internally for picking their values is very complex, and feels like it could change arbitrarily at any point in time. If I want to disable minification of exports and imports reliably, what is the intended way to do it? I see that at present -lexports.js will do it but I'm not sure if that's a good solution (and I don't love that it increases code size a little bit.)

Thanks!

[kripken]

I think -lexports.js is the best way to do that atm. It's not directly intended for that, but it reads the export names so it forces them to stay unminified. And it should only add a few extra bytes of overhead on top of the lack of relevant minification.

I'm curious why you want to disable this minification, though? (In general the ABI between the wasm and JS is not mean to be inspectable.)

[kg]

We have code that needs to grab the raw wasm exported functions out of the Module so it can insert them into the function pointer table. Using cwrap doesn't guarantee that the return value will be the raw function instead of a JS wrapper.

[kripken]

Interesting. Rather than export those functions, could you add them to the table at compile time? (I think a larger table is more compact than a longer list of exports, at least in the wasm binary - but maybe not at runtime?)

[sbc100]

We have had this request before I think, but I'm struggling to remember exactly where from and why.

In general, as will all settings we prefer to keep them internal if we possibly can. Emscripten suffers pretty badly from combinatoric settings explosion. So we could try to look into other options before exposing this one.

[kg]

Interesting. Rather than export those functions, could you add them to the table at compile time? (I think a larger table is more compact than a longer list of exports, at least in the wasm binary - but maybe not at runtime?)

Yeah, one option I was considering is getting their location in the table and using that to fetch them out of it. If that is what you recommend I might dig in more to try and figure out the best way to do it - maybe a C function that returns their address out of a dispatch switch statement or something. The code bloat would probably not be too bad. For now I'm testing out -lexports.js but I haven't gotten it to work yet.

Your point about the table being more compact than exports is a good one. If we could avoid exporting them, that would compensate for the cost of the 'give me a fn pointer' helper function. Thanks!