Non-async source map.

[ahmedcharles]

Is it possible to use the new Rust wasm lib-mapping without requiring support for async/await or futures, in general?

For context, I'm writing code in a context where all async operations are disallowed, which means that I'm stuck on 0.6.x of source-map. I was hoping to get the performance benefit of the wasm implementation but requiring async is a deal breaker.

[fitzgen]

Fetching and compiling WebAssembly is inherently async.

We could add a sync API to create a SourceMapConsumer given that you've already fetched and compiled the wasm. Would that work?

If so, I can help you craft a PR that implements this.

[ahmedcharles]

I'm not sure. Does node require an async interface for wasm? For reference, I'd like to use source maps with screeps (0.6.x works). Their docs for wasm is here: http://docs.screeps.com/modules.html It doesn't seem to include anything async, but I've also not tested it yet.

[SimenB]

A sync API is also needed for e.g. stack traces, as they are collected synchronously (evanw/node-source-map-support#206).

If we can initialize whatever needs to be async ahead of time, and have a sync way of constructing and using SourceMapConsumers, that would unblock Jest (and probably Babel) at least

[fitzgen]

Sketch of what would need to happen:

• Eagerly fetch / read the wasm in SourceMapConsumer.initialize and save it in some global within lib/source-map-consumer.js

• Return a promise from SourceMapConsumer.initialize that resolves after the wasm is instantiated, and therefore we can synchronously create new consumers

• Add a SourceMapConsumer.synchronouseNew (open to bike shedding on the name) function that throws if the wasm has not been initialized, and otherwise creates a new consumer synchronously

[ahmedcharles]

What if SourceMapConsumer.initialize or SourceMapConsumer.with or any other function that is async accepts the already loaded wasm file? In that scenario, you could just not return a promise and it would just work, no globals required.

[fitzgen]

I would prefer not to expose the wasm directly, since it is an implementation detail, and its interface may change. If we could wrap it up and hide the internals, then that could work.

[jasonLaster]

@loganfsmyth and I discussed this topic a couple weeks ago because a sync API is important for tools like babel.

[loganfsmyth]

I think the upfront-delay approach would be potentially reasonable in my mind, but it is painful in some cases. I've wanted to explore doing that for babel-register anyway. We'd definitely need a new major version of node-source-map-support that returned a promise that resolved once the WASM was finished loading, then other tooling could do a similar thing.

The main issue for babel-register is that a lot of people use it via node -r babel-register app.js, and I don't believe Node exposes a way for -r items to delay execution, so it would probably require some hackery to make that work by overwriting Node-private stuff :(

[ai]

PostCSS needs sync source map support as well. We use source map in throwing errors.

[devsnek]

I think the best option would be to load the wasm into the library source directly instead of distributing it separately. This would be a fairly trivial build step and fix this entire issue. You would need to use the sync interface of WASM (new WebAssembly.Module(buffer)) but it would definitely be worth it.

POC sync SourceMapConsumer https://github.com/devsnek/node-source-map-support/blob/master/source_map.js