Hey there, first of all thank you very much for your efforts, it looks great so far. I do have a few notes though:

• Your README says to build like so zig build webexport --sysroot [path to emsdk]/upstream/emscripten, but there is no webexport step. Building with zig build <example name> -Dtarget=wasm32-emscripten --sysroot [path to emsdk]/upstream/emscripten worked great for me.
• Using that command, building works without the updateTargetForWeb shenanigans on my MacBook
• The webExport function seems unused?

Additionally I'll add your getModule fix separately so the commit history is more clear.

Don't worry about the merge conflict, we'll cross that bridge when we come to it

Yeah, I still have some work to do in order to make it work more intuitively. I made it work based on the target for the examples, and webexport for the project but I think it would be best to build based on the target for both scenarios.

the webExport function is used in the project_setup.sh

updateTargetForWeb seems to not be required in some examples, but is required in others. The reason it's required is in the zig standard library std/c.zig is missing fd_t which causes an error.
I've submitted an issue to the Zig developers so they can fix it in the meantime.

Then I suggest we keep the updateTargetForWeb until that is fixed in a stable release of Zig.

I will convert this PR into a draft; do convert it back once you feel it is ready for review

I'm confused about the entry point. Couldn't we define the main function in Zig as an extern function with the C ABI? We'd still build a library, but not use C as an intermediary.

Try to make the main method extern, and you'll get an error: return type 'anyerror!void' not allowed in function with calling convention 'C'

Removing anyerror! builds fine, but emscripten doesn't treat it as an entry point since it expects it to return a c_int, which the main method isn't allowed to do in zig. I also don't want to rely on the exact type of main that someones project uses. (which the web build currently does, I'll have to find a way around that)

The intermediate C file isn't really a big deal anyway, since it's hidden and it all gets linked together nicely.
I think a bigger concern is the web_emscripten_entry_point.zig thing, since adding files to the source is really weird.

I did some more testing an apparently I've been wrong about emscripten's ability to find entry points this entire time. It's able to find zig's main method no matter what the function signature is, and errors even work properly.

I'm not sure if something changed since I last tested, or if I just missed something obvious, but either way I'm glad I found out because it means I can remove a lot of the hackiness here.

Looks good to me, if this is ready I'll merge it.

I think it's pretty much ready to merge, so go ahead if you think so too.