-
Notifications
You must be signed in to change notification settings - Fork 194
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
Missing core modules resolution behaviour #303
Comments
Hi @jpg0, to avoid lookup failures for core modules that are not available, you could map the Node.js core module name to an "empty" JavaScript file that simply does nothing. In this way, you would still be able to control what gets loaded and throw an exception if an application tries to load a module that you may want to block |
My use-case is more the opposite - I want to enable standard modules to work that depend on core modules by installing pure JS equivalents that already have the same name as the core module (rather than block anything). For example, I can install https://www.npmjs.com/package/events as a module, but other modules cannot use it, unless I (a) remap it to something else and (b) then rename the module to the the remapped name. Ideally I'd like to be able to tell GraalJS to just ignore core modules entirely and load (or fall-thru to loading) them as standard modules, or even allowing me to 'remap' the core module to a standard module of the same name would work. |
OK, thanks for the clarification. Yes, I think we can support your use case then. I will update this issue once ready. |
Fixed by this commit |
Thanks! |
I am currently embedded GraalJS and using experimental CommonJS module support.
There are various places where modules are loaded which depend on node core modules, but for which a community provided replacement exists, such as 'events'. I understand that I can override the module loading behaviour to remap this to 'custom-events' or whatever.
My question is that if there are no core modules defined when embedding, why reject the normal module lookup mechanism when attempting to resolve them? Why not allow lookup via the specified name anyway (unless remapped)? We know that any core module will completely fail lookup otherwise.
The current behaviour would also require me to rename all the modules which possess the original node module name (such as the 'events' example).
Thanks
The text was updated successfully, but these errors were encountered: