Can we have a synchronous call

[paulhiggs]

While Promises and asynchronous programming is all good in the context of JavaScript and Node.js, it is hard to include this API into a large existing codebase that is fully synchronous.
Ideally need to

1. validate
2. parse the errors
3. copy errors into a separate container

1 and 2 can be done asynchronously and writing errors to console is, of course, ok, but 3 does not happen.

[noppa]

Two problems with that:

Technical. Initializing the WebAssembly module is in it's recommended form an async operation. There is a synchronous API but its use is discouraged. At least Chrome seems to impose a 4K hard limit on the module size if using the sync version. So that pretty much leaves the newly implemented browser API out of this discussion. Could possibly work on Node, though. There's relevant discussion at this mozilla/source-map issue, which is about them changing to fully asynchronous API because their implementation is now wasm-based. The current compiled wasm binary for this library is about 800K. There's probably room to trim, but reaching 4K seems unrealistic.

Architectural. The current Node implementation launches a Worker thread to isolate the libxml2 from the main thread. I originally did that to prevent the emscripten compile result from calling process.exit when the library exits, or doing anything else "command-liney" like that when it's used in an application context and not just a CLI. There's probably other ways to do that, though, with some emscripten configuration options.

However, I don't personally have use for a synchronous API so honestly it's unlikely that I'll spend time on implementing this in the near future at least. Also it should be considered that if the architectural changes make it very different from the current implementation and essentially split/duplciate the codebase, maybe at some point it stops making sense to include it here at all and just make a separate repo/package.

So to summarize,

For browsers: No.
For Node: Maybe, if someone else wants to do the work 😄 (I'm happy to give advice / pointers tho).

---

Can you provide a bit more concrete examples about what you are trying to do and the issues with

3. copy errors into a separate container

maybe there's something that can be done there to make it support async without re-architecting the whole app.

If your app allows this kind of architecture, you could also separate the xmllint part into its own little Node.js application and just execSync from the main application, effectively making the main application block until this async part finishes. That's a bit of a hack I guess and comes with a performance cost, but could also be an alternative to re-architecting large chunks of existing code.

[noppa]

Closing as not planned. I'm willing to consider this if there's enough interest for someone else to implement it 😄 But I don't have a personal use case for this, and most likely fixing the application-side to be async, or making it do some tricks with blocking process invocations, would be the easier route to take.