[browser][coreCLR] Skeleton for JavaScript host

[pavelsavara]

Skeleton for JavaScript host

The goal on this PR is to establish directory structure and naming.

All new *.js files are

• hand written skeleton and PoC for now.
• It will be replaced by TypeScript sources in better quality in next PRs.
• later most of them would be generated into artifacts\obj
  • like artifacts\obj\native\<RID>\System.JavaScript\ next to libSystem.JavaScript.a

New files

• src\native\corehost\browser\
  • this is targeting NodeJS for now
  • libBrowserHost.js - implements external_assembly_probe callback
  • browserhost.cpp - creates coreCLR instance
    • statically linked
    • no path probing or host policy
    • passing TRUSTED_PLATFORM_ASSEMBLIES as env var for the PoC, to be improved.
  • demo files
    • At the moment clumsy and to be simplified.
    • index.html - target web page
    • main.mjs - this is demo of the NodeJS usage.
    • dotnet.boot.js - list of assets to download. This going to be generated by MSBuild of the WASM SDK later. It's 100% compatible with Mono/Blazor
• src\native\libs\Common\JavaScript
  • shared type definitions and small helpers connecting our JavaScript modules
• src\native\libs\System.JavaScript\
  • Emscripten library with native functions for runtime PAL and ICalls
  • libSystem.JavaScript.js - JS part of the library
  • libSystem.JavaScript.extpost.js - ES6 exports helpers
  • CMakeLists.txt, entrypoints.c - native part of the library. C exports for P/Invoke.
• src\native\libs\System.Runtime.InteropServices.JavaScript\
  • Emscripten library with native functions for JS interop
  • libSystem.Runtime.InteropServices.JavaScript.js - JS part of the library
  • CMakeLists.txt, entrypoints.c - native part of the library. C exports for P/Invoke.
• src\native\libs\System.JavaScript.Loader\
  • ES6 JavaScript module representing public JS API and a loader/host
  • it will produce dotnet.js file in the final product.
  • the module downloads other JS modules, DLLs and other assets.
  • needs to be small so that it would start the download cascade quickly
• src\native\libs\System.JavaScript.Runtime\
  • ES6 JavaScript module with the JS interop marshallers
  • it will produce dotnet.runtime.js file in the final product.
• src\native\libs\
  • root of the JavaScript build
  • package.json, package-lock.json, .npmrc - npm package definition and dependencies
  • .eslintrc.cjs, .eslintrc.cjs - JS code style
  • rollup.config.js - JS bundler and build script for TypeScript
  • tsconfig.json - typescript configuration

Q & A

• Q: why is System.JavaScript.Loader not part of corehost\browser folder ?
• A: because rollup/npm/typescript build needs common root folder. Moving it to src\native doesn't seem great choice.
• Q: could we move all the JS mess into src\native\libs\JavaScript ?
• A: Yes, but some of it is also native C libs. Similar to System.Security.Cryptography.Native.Android.
• Q: could we merge System.JavaScript.Runtime folder into System.Runtime.InteropServices.JavaScript folder ?
• A: Yes, if that's preferable. It would still produce 2 .js files and one .a file
• Q: does this support C code trimming
• A: not yet, until we generate list of P/Invoke dependencies from IL trimmed assemblies
• Q: does this support JS code shaking and symbol minifications
• A: It would (to some degree) once we bring TS. Protecting symbols from Emscripten is complex topic.
• Q: there are similar files in src\mono\browser\runtime, are we going to reuse them ?
• A: we are going to reuse best ideas, but keep Mono code as is in place
• Q: could we produce runtime without JavaScript interop assembly ?
• A: Tentative yes. I'm working on it. The challenge is that async C# Main() needs to yield to browser event loop and marshal Task/Promise. Synchronous main is not very useful in JS.

Fixes #119685
Contributes to #113067

[dotnet-policy-service]

Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov
See info in area-owners.md if you want to be subscribed.

[pavelsavara]

Together with #119591