Added support for JS modules and importmaps

[tomvanenckevort]

Types of Changes

Prerequisites

Please make sure you can check the following two boxes:

• [x] I have read the CONTRIBUTING document
• [x] My code follows the code style of this project

Contribution Type

What types of changes does your code introduce? Put an x in all the boxes that apply:

• [ ] Bug fix (non-breaking change which fixes an issue, please reference the issue id)
• [x] New feature (non-breaking change which adds functionality, make sure to open an associated issue first)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)
• [ ] My change requires a change to the documentation
• [ ] I have updated the documentation accordingly
• [x] I have added tests to cover my changes
• [x] All new and existing tests passed

Description

As described in #92, this PR adds support for handling new ECMA JS modules and importmaps.

• Updated JsScriptingService to also handle the module and importmap types (for <script type="module"> and <script type="importmap"> elements).
• Updated EngineInstance to run different Jint routines based on the type passed in:
  • JS mime type: evaluate the script like before.
  • module: import the module source.
  • importmap: parse the import map, create a list of modules to import based on document path and then import them.
• Added JsModuleLoader to use the ResourceLoader to fetch any external scripts imported from inside another module.
• Added unit tests to test the new feature.

Note: to enable the deserializing of the importmap JSON I added a reference to System.Text.Json to the project, which would become an additional dependency of the NuGet package. I don't see any issues with that, but let me know if you think otherwise.

[tomvanenckevort]

Also the scopes for importmodules are imho not correctly in there - but I think this will be difficult if Jint does not support dynamic resolution.

Could you elaborate a bit more on that?

[FlorianRappl]

Could you elaborate a bit more on that?

Yeah so what I meant is that the scope field gives ESM modules different parts, e.g.:

• general imports, "react" -> "react1.mjs"
• specific one scope to "/foo/*" -> "react" -> "react2.mjs"

Now starting with some imports each one would resolve "react" to "react1.mjs", while an import of a module "foo/something.mjs" would find "react2.mjs" when importing "react". This, however, cannot statically be set, but only when resolving the module (i.e., when Jint would find an "import" statement it would go to the dynamic resolver with the current module's metadata - most importantly its URL - to find what module is actually meant / requested here).

The scope's are not dependent on the document's path (surely, in a way they are - as this is the base path for all relative paths, but once you import from https://esm.sh/... other modules are also imported relative to this one).

[tomvanenckevort]

I've refactored the importmap scopes to work as intended (based on the path of the importing script, rather than the path of the document).

[FlorianRappl]

I've refactored the importmap scopes to work as intended (based on the path of the importing script, rather than the path of the document).

Awesome - thanks!

The only thing that keeps me at the moment from merging is that the Linux build (or rather the tests) is failing. I did not have yet the chance to look into it, but it should definitely also work on Linux.

[tomvanenckevort]

Yes, was going to try and have a look at that one today as well.

[FlorianRappl]

You are the man! GJ! 🚀