(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.