Feature request: Have a way to tell Emscripten NOT to export a module so that I can control the modularization myself

[Taytay]

(I brought this issue up in issue #5820, but @curiousdannii pointed out that I was conflating issues and recommended a new issue:
#5820 (comment) )

For this issue, since we'll be talkinga bout the Emscripten Module object and Node modules, I will refer to the Emscripten Module as GeneratedModule and will refer to node modules as simply "module".

I would like for Emscripten to allow me to control how the Emscripten GeneratedModule object is exported. Currently, both MODULARIZE=0 and MODULARIZE=1 assume that I would like to export the GeneratedModule object as the main export. In my case, I would like to create a Node module that exports a function as its main/default export instead.)

When I brought this up in the other issue, @curiousdannii said:

Emscripten expects to be run in a CommonJS environment, and if you use it in another environment that still has a module of course it will get into trouble. I'd recommend you use browserify/webpack/rollup instead of cating files.

I am indeed running this in a CommonJS environment (Node), and purposefully so, which is why I have a module object that Emscripten's code detects and performs its export. The issue I am running into is that I would like to control how my generated code gets modularized/exported rather that using Emscripten's generated code to do it. Right now I have two choices:

1. I can use MODULARIZE=1, which will wrap everything in a function for me, but will still export the Module object as its primary/default export. (And furthermore, currently adds an unwanted then
   method that causes issues being addressed in issue Undocumented Module.then causes infinite loop #5820.

2. Use MODULARIZE=0, which I assumed would leave me in charge of modularizing it myself, but the following lines actually say, "Even if they don't want me to 'modularize' the code and wrap it in a function, I'll still ensure that the Module gets exported if they are in a CommonJs environment.":
   https://github.com/kripken/emscripten/blob/3e193554813643458a506e299c49cbf6c53fe4e9/src/shell.js#L149-L151
   This assumption is also made here in More consistent UMD exports and then() support #6477, but with UMD exports, etc
   More consistent UMD exports and then() support #6477

I wanted the freedom to say, NO_REALLY_DONT_EXPORT_ANYTHING_I_WILL_HANDLE_IT=1 so that I could leave Emscripten in control of generating the code, but leave me in charge of wrapping/exporting/modularizing it.

@curiousdannii, were you suggesting that if I really want control over how Emscripten's output gets modularized, that I should instead write a new Node module that imports the exported Emscripten GeneratedModule, and then re-exports it as I see fit? Then, to bundle all of that into a single file that my library users can embed/use, I should use Webpack? If so, that a valid approach. I was trying to avoid adding a bundler like Webpack as a development dependency in Sql.js other other WASM libraries where I want to control the export of my module, and I thought that pre-js and post-js options were the easiest/recommended ways to proceed.

[curiousdannii]

The MODULARIZE option is perhaps misnamed - it changes Emscripten's output to a factory function. It doesn't inherently have anything to do with exporting to any JS module system (UMD or ES modules).

But it wouldn't be hard to add an option to remove all exporting code. I'd consider it inferior and less safe for most people, but I don't see much of a reason it shouldn't be added.

What I was suggesting to you was to require('output.js') or import "output.js" (with the EXPORT_ES6 option) your Emscripten generated code in your main library. There are several bundlers that could then wrap that all up into one file, and some like Rollup would produce 0 overhead code too. It's an extra tool to install, but these tools are simple to invoke and pretty reliable so I wouldn't consider that a downside. But that's just my suggestion.

[curiousdannii]

So the simple way to do this would be to just add an new option. Alternatively EXPORT_ES6 could be depreciated, and EXPORT_METHOD could be added, with none, umd, and esm/es6 options.

[Taytay]

Excellent - that's helpful @curiousdannii! I did indeed misunderstand the purpose of MODULARIZE, even after working with that code a fair amount. I conflated two things - what is being exported and HOW it's being exported.

Thanks for point me to Rollup! I wasn't familiar with that. As part of my work on SQL.js, I want to give people an opinionated way to consume the library, but was hoping to introduce less maintenance on the development side. I think you're right that one of these tools is going to be low-enough-overhead as to make sense.

I really like the EXPORT_METHOD options idea. I feel like it's the most future-proof since, even now, people have varying opinions and requirements on the best way to perform exports.

[GordonSmith]

I am not sure what the solution is, but I do agree we need better control over the generated JS in general. Specifically (in my case) I don't think the location of the WASM file (for the fetch) will be 100% correct in all cases and I would like the ability to override it...
Also I am not sure "fetch" is desirable in all situations (especially when trying to load the WASM via a file:// URN)

EDIT: I see there is a "locateFile" hook in Module which solves 1 issue...

[stale]

This issue has been automatically marked as stale because there has been no activity in the past year. It will be closed automatically if no further activity occurs in the next 7 days. Feel free to re-open at any time if this issue is still relevant.

[curiousdannii]

I still like the EXPORT_METHOD idea, so lets keep this open a little while longer.

[stale]

This issue has been automatically marked as stale because there has been no activity in the past year. It will be closed automatically if no further activity occurs in the next 30 days. Feel free to re-open at any time if this issue is still relevant.