-
-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Added support for JS modules and importmaps #93
Added support for JS modules and importmaps #93
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is good - we should just see if we can get rid of the dependency on system.text.json. Rest looks great to me.
Also there are some cases that potentially require a bit more code, but we can also cover those later (e.g., that paths are mapped correctly and that non-ESM vs ESM behaves as it should).
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? |
Yeah so what I meant is that the scope field gives ESM modules different parts, e.g.:
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). |
I've refactored the |
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. |
Yes, was going to try and have a look at that one today as well. |
You are the man! GJ! 🚀 |
Types of Changes
Prerequisites
Please make sure you can check the following two boxes:
Contribution Type
What types of changes does your code introduce? Put an
x
in all the boxes that apply:Description
As described in #92, this PR adds support for handling new ECMA JS modules and importmaps.
JsScriptingService
to also handle themodule
andimportmap
types (for<script type="module">
and<script type="importmap">
elements).EngineInstance
to run different Jint routines based on the type passed in:JsModuleLoader
to use theResourceLoader
to fetch any external scripts imported from inside another module.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.