noVNC cannot be bundled due to top-level await in browser.js

[mudge]

Describe the bug
3677afe introduced a top-level await in lib/util/browser.js which prevents the library from being bundled with esbuild when previously it was fine.

To reproduce
Steps to reproduce the behavior:

1. In a new directory, run npm install -S @novnc/novnc esbuild
2. Create an index.js with import RFB from "@novnc/novnc";
3. Attempt to bundle the file with npx esbuild index.js --bundle
4. See errors like the following:

   ✘ [ERROR] This require call is not allowed because the imported file "node_modules/@novnc/novnc/lib/util/browser.js" contains a top-level await
   
       node_modules/@novnc/novnc/lib/rfb.js:11:23:
         11 │ var _browser = require("./util/browser.js");
            ╵                        ~~~~~~~~~~~~~~~~~~~
   
     The top-level await in "node_modules/@novnc/novnc/lib/util/browser.js" is here:
   
       node_modules/@novnc/novnc/lib/util/browser.js:179:68:
         179 │ exports.supportsWebCodecsH264Decode = supportsWebCodecsH264Decode = await _checkWebCodecsH264DecodeSupport();
             ╵                                                                     ~~~~~
   

Expected behavior
The file bundles successfully.

Server (please complete the following information):

• noVNC version: 1.6.0
• esbuild version: 0.25.1
• Node version: v20.9.0
• OS: macOS 15.3.1

Additional context
This happens even when using esbuild's default target of esnext. Is it possible to compile a version of browser.js that does not use a top-level await?

[SteveW94]

Sadly had to revert back to 1.5.0 also due to this issue :/

[CendioOssman]

I don't think modules were designed with bundling in mind, so I suspect this will always be a bit shaky.

Bundling is also not something we've set out to explicitly support, so off the bat this would be an esbuild issue rather than a noVNC one. They seem to already be tracking it as evanw/esbuild#253.

As for not using top level awaits; that is not something we can commit to. Most web APIs are asynchronous. Using this construct allows us to avoid a lot of complexity and bugs.

I see you are using noVNC from npm, though. That is code that's been converted to CommonJS. What happens if you use the original noVNC code?

[SteveW94]

Hm I see...
Well it seems on the esbuild side, nothing has happend really for quite a long time there.
Regarding npm: Why is the code converted there? Are you suggesting to copy paste the plain code in our project? I can say that for any kind of production use we will have to rely on npm to keep automatic updates, license tracking etc etc. to work and wont copy static libs in.

So I guess the current question is, if there can be some kind of work around imagined, either possible from our side bundling it or from your side somehow.
I think at least from my projects perspective we would have to pin noVNC to 1.5.0 if not.

[CendioOssman]

Regarding npm: Why is the code converted there?

Because npm is primarily the domain for Node.js, which uses CommonJS rather than "regular" JavaScript. Also, since noVNC is for the web and not Node.js, npm support has always been a very secondary priority for us.

I've seen that npm has grown support for ES modules, and some support for modules targeting the web. But it's not something anyone has investigated how that could be useful for noVNC.

Are you suggesting to copy paste the plain code in our project? I can say that for any kind of production use we will have to rely on npm to keep automatic updates, license tracking etc etc. to work and wont copy static libs in.

Yes, our primary distribution form is releases on GitHub. That is what we develop and test for.

So I guess the current question is, if there can be some kind of work around imagined, either possible from our side bundling it or from your side somehow.

The currently problematic line is only for H.264 support, which you likely don't need. So you could try patching it out.

If it works with our original code (rather than the CommonJS code in the npm package), then it could be worthwhile for someone to investigate npm's new support for ES modules.

[SteveW94]

I see, I will try if I can figure something out regarding the .H264 Support.

And on the side always learning sth new^^ As for me, "CommonJS" was always the synonym for "regular" basic Javascript and the standard to expect. Compared to that I considered this whole module-esm stuff as the the new fancy way which as you said coming slowly and might be (and is even already) supported to get loaded natively by the latest node-versions.

[elikoga]

I am experiencing a similiar problem when bundling using rollup, however it's error message is a bit clearer:

[commonjs--resolver] node_modules/@novnc/novnc/lib/util/browser.js (179:74): await isn't allowed in non-async function

Which tells us that the problem is that CommonJS files don't allow top-level-await. A quick look at https://babeljs.io/docs/babel-plugin-syntax-top-level-await tells us an issue:

Babel doesn't support transforming top-level await, but you can use Rollup's experimentalTopLevelAwait or webpack@5's experiments.topLevelAwait options.

So the root-cause/issue is the following: Babel fails to translate ES -> CJS top-level-awaits and downstream tooling complains that top-level-awaits are not allowed in CJS, even when translating CJS -> ES

---

I've seen that npm has grown support for ES modules, and some support for modules targeting the web. But it's not something anyone has investigated how that could be useful for noVNC.

I actually use noVNC for a browser client distributed through npm and was not aware of that, it worked so well before!

It looks like Node added support for ES Modules in Node 12 or so (see History), which can be enabled by setting "type":"module" in the package.json. Then, one can remove the CommonJS conversion step and distribute the same source package for both Node and Browsers. Since ESBuild already supports top-level await for ES Modules, fingers crossed 🤞, one can use NoVNC >=1.6.0 distributed via NPM in Browsers Processed with esbuild, just like before.

If it works with our original code (rather than the CommonJS code in the npm package), then it could be worthwhile for someone to investigate npm's new support for ES modules.

I will probably spend some time trying out some approaches to unblock Thymis-io/thymis#439 which broke due to the update.

[elikoga]

If it works with our original code (rather than the CommonJS code in the npm package), then it could be worthwhile for someone to investigate npm's new support for ES modules.

It works for me with ES Modules.

A PR has been opened that changes the published NPM Package to use ES Modules instead of shipping invalid CommonJS