You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, Javet’s Node engine enforces a custom module resolution mechanism for ESM modules, which prioritizes security. While I understand and appreciate the security benefits of this approach, it can be limiting for certain use cases where the standard Node.js module resolution would be preferable.
I am aware that JavetBuiltInModuleResolver exists, but it is limited to resolving Node.js built-in modules. For more complex scenarios involving user-defined modules or dynamic resolution patterns, this is insufficient.
Although it is possible to implement a custom IV8ModuleResolver, reimplementing Node.js native module resolution is complex and error-prone, given the intricacies of its behavior.
Example code:
varruntime = V8Host.getNodeInstance().createV8Runtime();
varresolver = newJavetBuiltInModuleResolver();
runtime.setV8ModuleResolver((runtime1, specifier, referrer) -> {
// here I could implement the same algorithm as Node.js, but the algorithm is complex and can be changedreturnresolver.resolve(runtime, specifier, referrer);
});
varexecutor = runtime.getExecutor(...);
executor.setModule(true);
executor.executeVoid();
Proposed Solution
Introduce an option to enable the standard Node.js ESM module resolver for the Node engine. This could be implemented as an opt-in feature, maintaining the current secure defaults while providing greater flexibility for advanced users.
Use Cases
1. Projects that rely on dynamic or non-trivial module resolution behaviors supported natively by Node.js.
2. Developers who need seamless integration with existing Node.js ESM workflows without having to replicate module resolution logic.
3. Scenarios where strict security restrictions are unnecessary or already handled elsewhere in the environment.
Thank you for considering this enhancement! Let me know if I can provide more details.
The text was updated successfully, but these errors were encountered:
Thank you for raising this issue. You are not alone.
There have been many Javet users asking for this for a couple of years. It's not easy to implement that without hacking the Node.js source code.
But, in general, I think it's technically achievable. My plan is as follows.
Create public class NodeModule extends V8Module.
Add public NodeModule createNodeModule(...) to NodeRuntime.
Thus, NodeRuntime will support both V8Module (supports module resolver) and NodeModule (doesn't support module resolver).
Please be aware that this will be a big feature that requires certain amount of time. You are welcome discussing that with me in real-time at discord, if you have any questions / suggestions.
Description
Currently, Javet’s Node engine enforces a custom module resolution mechanism for ESM modules, which prioritizes security. While I understand and appreciate the security benefits of this approach, it can be limiting for certain use cases where the standard Node.js module resolution would be preferable.
I am aware that
JavetBuiltInModuleResolver
exists, but it is limited to resolving Node.js built-in modules. For more complex scenarios involving user-defined modules or dynamic resolution patterns, this is insufficient.Although it is possible to implement a custom
IV8ModuleResolver
, reimplementing Node.js native module resolution is complex and error-prone, given the intricacies of its behavior.Example code:
Proposed Solution
Introduce an option to enable the standard Node.js ESM module resolver for the Node engine. This could be implemented as an opt-in feature, maintaining the current secure defaults while providing greater flexibility for advanced users.
Use Cases
1. Projects that rely on dynamic or non-trivial module resolution behaviors supported natively by Node.js.
2. Developers who need seamless integration with existing Node.js ESM workflows without having to replicate module resolution logic.
3. Scenarios where strict security restrictions are unnecessary or already handled elsewhere in the environment.
Thank you for considering this enhancement! Let me know if I can provide more details.
The text was updated successfully, but these errors were encountered: