improve wasm support

[FreyLuis]

I found a few issues while setting up WASM benchmarks & would like to fix those. Since those would include breaking changes, I’m asking about them here before starting any work.

• Currently --expose_wasm is the default parameter for javaScriptEngineArguments, but the flag was removed in 2024.
• The JS entry point is hardcoded to be AppBundle/test-main.js (or AppBundle/main.js with .net 5 / 6). The user then has to create the file under the correct path & still needs to set the WasmMainJSPath as an msbuild argument. The path shouldn’t be hardcoded & BenchmarkDotNet could autogenerate the file.
• The default parameter for the .net monikers are still .net 5. IMHO, those should either be removed or replaced with factory methods (CreateWasm10_0(string javaScriptEngine, string javaScriptEngineArguments, bool aot)).

The docs are also outdated (already tracked by #1818):

• The current example only describes how to set benchmarks up using a custom dotnet runtime. This is unnecessary and looks scary to anyone not working on dotnet itself.
• The example also recommends using v8 directly via jsvu, which does not provide standard JavaScript APIs. Dotnet relies on these APIs (for creating GUID’s, it uses crypto.getRandomValues() for example). IMHO, recommending node might be the better choice.

Would you accept such a PR, or is someone already working on something similar?

[timcassell]

• The default parameter for the .net monikers are still .net 5. IMHO, those should either be removed or replaced with factory methods (CreateWasm10_0(string javaScriptEngine, string javaScriptEngineArguments, bool aot)).

I have mentioned in the past that the default moniker should probably use the current runtime version, but no one seemed interested in doing it.

We are definitely open to accepting PRs that update the wasm toolchain. Just make sure you validate any changes against dotnet/performance.

[timcassell]

• Currently --expose_wasm is the default parameter for javaScriptEngineArguments, but the flag was removed in 2024.

That probably explains my issue in #2675. Maybe we can enable Windows support with your updates.

[FreyLuis]

@timcassell Sure, I was already wondering what blocks windows support. I believe that the run-v8.sh script generated with the WasmGenerateRunV8Script MsBuild Property also contains the flag, but BenchmarkDotNet doesn't use the script, so this isn't an issue here.

Would it be fine to completely remove the wasmDataDir command line argument? I believe it's not actually an option in the WebAssembly SDK and just used here in dotnet/performance to set the main.js path. Instead, we could add a wasmMainJsPath option.