User-inputted module's `main` call called twice

[JordanMartinez]

Opening up https://try.purescript.org/, I see that the module's main function is called twice, again. I thought this was fixed by #279, but maybe the recent es-module-shims update to 1.5.9 broke something?

[andys8]

In case the issue has its root cause in es-module-shims there are two commits in recent releases that mention "initialization". Maybe interesting.

guybedford/es-module-shims@1.5.9...1.5.12

Update: I don't think this will fix the issue.

I could reproduce the issue in Firefox, but not in Chrome. Could be browser or version related (e.g. one needs shims and the other doesn't).

https://discord.com/channels/864614189094928394/869607074152206397/1007075896005492837

[andys8]

I think I found the issue:

The docs of es-module-shims have this paragraph:

This execution failure is a feature - it avoids the polyfill causing double execution. The first import being a bare specifier in the pattern above is important to ensure this.

This is not the case for try.purescript.org. Adding import react from 'react'; as the first import would indeed lead to a working example in both Chrome and Firefox.

An alternative described in the docs is to activate shimMode.

window.esmsInitOptions = { shimMode: true }

Shim mode is an alternative to polyfill mode and doesn't rely on native modules erroring - instead it is triggered by the existence of any <script type="importmap-shim"> or <script type="module-shim">, or when explicitly setting the shimMode init option.

[JordanMartinez]

Yup, that's probably it.

[pete-murphy]

Still seeing this issue in Firefox (104.0b10 (64-bit))

[andys8]

Cool, I see it both working (locally, 25a9095) and not working (try.purescript.org) at the same time using Firefox 103. Either there is a difference (not same code state, but I don't think so because the new comment is part of the html), frames behave differently on the domain compared to localhost or its depending on (load) times or other external influence.

screencast-2022-08-27_19.52.49.mp4

That makes it harder to reproduce locally, but the main issue is still the combination of iframes, settings listeners once, and es-module-shims intentionally crashing and executing scripts again. This combined with the fact that render is using setInnerHTML which doesn't set - but append - is brittle.

Options

• Mess with es-module-shims or a larger change regarding listeners (once: true) and iframes
• Using a different solution for modules, adding npm dependencies differently (but probably not easy to find a better alternative)
• Add an additional script, importing a module, hitting the intentional error earlier (<script type="module">import uuid from 'uuid';</script>). Without being able to reproduce locally, I don't know if this would fix the render issue in Firefox
• Change setInnerHTML and therefore render to be idempotent and set the content (and not append to it). This would change the behavior, in case you intentionally have multiple render calls. But if possible, this would be the easiest and likely (for the user) the most robust change.

[JordanMartinez]

For what it's worth, every time I've tried fixing this locally, it appeared to be fixed locally only for it to not be fixed on the actual site. Hence, it's hard to know when this problem has actually been solved.

[andys8]

Is the last suggested option viable?