Is `delete()` necessary to avoid memory leaks, if I allow a SourceMap instance to be GCed by JS?

[parcel-bundler]

Is `delete()` necessary to avoid memory leaks, if I allow a SourceMap instance to be GCed by JS?

[devongovett]

With the WASM version, yes, delete is necessary. With the node version it is not.

[cspotcode]

I'm trying to understand the WASM version better, and I can't find the WASM artifact in the npm package.
https://unpkg.com/browse/@parcel/[email protected]/parcel_sourcemap_wasm/

Am I looking in the wrong place, or doing something unsupported?

> require('@parcel/source-map/dist/wasm-bindings')
Uncaught:
Error: Cannot find module '../parcel_sourcemap_wasm/dist-node/parcel_sourcemap_wasm.js'

[mischnic]

Huh, they are missing from 2.0.1 and newer...

https://unpkg.com/browse/@parcel/[email protected]/parcel_sourcemap_wasm/
https://unpkg.com/browse/@parcel/[email protected]/parcel_sourcemap_wasm/
https://unpkg.com/browse/@parcel/[email protected]/parcel_sourcemap_wasm/

[mischnic]

Are you trying to use the Wasm version from Node or in the browser? Looks like we only build the browser version anyway (which works fine with version 2.0.0 and a bundler that uses the browser field in package.json)

To give more background to the delete question: the SourceMap wrapped object will be GCed, but not associated memory in the Wasm memory block. At some point in the future, we could use FinalizationRegistry to run delete automatically.

Another thing you need to do in the wasm version is await the init export

source-map/src/wasm.js

Line 8 in c4b0b24

export const init: Promise<void> = typeof bindings.init === 'function' ? bindings.init() : Promise.resolve();

so that all other operations don't have to wait for the Wasm instance to be loaded and can be synchronous (= what top-level-await was built to solve).

[cspotcode]

Ok thanks. Yeah I was trying to use the wasm version from node. For my use-case, it's important that I automatically and silently fallback to a non-native binary in case the native binary fails in a target environment, so I was testing if that would work. I think the async bootstrapping might also be a deal-breaker, due to legacy constraints in my project, though I do understand why WASM often necessitates it in browsers.

I appreciate your taking the time to share this information, thank you.

[mischnic]

The Wasm-in-Node usecase wasn't needed by anyone so far. But in Node, this could be implement without async as well (readFileSync + new WebAssembly.Module(buffer)).