ModuleMap::clear_module_map should be rearchitectured #363
Assignees
Comments
This was referenced Dec 4, 2023
bartlomieju
added a commit
that referenced
this issue
Dec 6, 2023
…369) A new "ModuleMap::resolve" function was added that is now used in favor of directly calling "loader.resolve". This method performs additional checks that prohibit resolution of "ext:" modules from modules that are not "ext:" or "node:" modules. This will allow us to sunset "RuntimeOptions::preserve_snapshotted_modules" and will greatly help with lazy loading ES modules for internal runtime code. A bit different approach than suggested in the issue, but closes #363.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Working on #263 we discovered that
ModuleMap::clear_module_mapis quite questionable way to interact with the runtime when snapshot is provided. Its purpose is to remove all modules from the module map but the ones passed as an argument. We use this method after we deserialize a snapshot, to remove allext:modules and leavenode:modules intact.In #263 we need a way to load
ext:modules during runtime, so as a temporary hack we added a fewext:modules to exclusions, but that's not a great solution. I think we need to rearchitect how module loading/resolution works, by always leaving all modules coming from the snapshot in the module map, but only allow importingext:modules from otherext:modules (ie. user code should still not be able to load any of theext:modules directly).The text was updated successfully, but these errors were encountered: