-
-
Notifications
You must be signed in to change notification settings - Fork 36
fix: issue with node_module resolving #149
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
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.
The primary fix of package_exports -> package_json looks like a solid bug fix for the default import. However, I believe this would introduce a different bug that would prevent importing of paths from a node module.
But at the moment the implementation wouldn't work at all. |
|
Yeah, the implementation is very broken at the moment. It went unnoticed because most packages have But you ought to be able to do stuff like this too: import z from 'zod/v4';Ignore for a moment the fact that zod's If we insert It works like this... const String file_path = p_module_id.substr(package_name.length() + 1);
if (check_package_file_path(absolute_package_path, file_path, o_source_info))That String DefaultModuleResolver::resolve_package_export(const Dictionary& p_exports, const String& p_condition, const String& p_module_id)
{
String lookup_key = p_module_id.is_empty() || p_module_id == "."
? "."
: "./" + p_module_id;Because Then we look through the (generated in this case) package exports for the longest matching prefix. |
Maybe we can add multiple npm packages inside this PR to test it? |
closes #102