fix: registry importModule function

[inglkruiz]

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)

Proposed changes

Use parsedModule.module instead of module, module contains the version installed, therefore importing the module results in an error because the folder does not exists in node_modules. See screenshot.

Bug introduced here > #3645

Checklist

• I have read the contribution guidelines
• For non-bugfix PRs, I have discussed this change on the forum/slack team.
• I have run grunt to verify the unit tests pass
• I have added suitable unit tests to cover the new/changed functionality

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: inglkruiz / name: LuisK Ruiz (80cf63d6576518bac6a5602c64335ad3460f982c)

[inglkruiz]

@knolleary Hi, could you review this PR? sorry for bothering you.

[knolleary]

Hi @inglkruiz

Sorry for the delay. It wasn't immediately obvious what this PR was fixing, because loading external modules was working fine here. I see now it occurs if you specify a version as part of the module name in the Function node - ipfs-http-client@56.0.3.

Once I understood what it was fixing, it was much clearer to review.

[coveralls]

Coverage: 68.257% (-0.0%) from 68.257% when pulling 04b36e7 on inglkruiz:fix/registry-import-module into 113d42e on node-red:master.

[inglkruiz]

@knolleary Thanks for paying attention to it. I have one more question, the package I'm using ipfs-http-client has migrated to ESM and I'm trying to making it work in NodeRed. One of the contributors suggested this > ipfs/js-ipfs#4265 (comment)

[inglkruiz]

I forgot to ask, do you think that could work? I understand he's suggesting us to remove const modulePath = createRequire(moduleDir) and use only the dynamic import function.

[knolleary]

The problem is ESM is a mess. There is no one-size-fits-all solution if you need to load any module without knowing ahead of time what flavour of ESM/CJS, what settings they may or may not have included in their package.json and a million other bits of incompatibility between the different module types.

It's fine if you're writing the code directly, as you can write whatever is needed for the given module. But we have to try to handle everything in Node-RED.

The code we have today came as a result of testing lots of different ESM and CJS modules to try to find something that works somewhat consistently for the set of modules we were testing with.

Any changes to this code will need testing against lots of different modules to ensure absolutely no changes in behaviour for existing users. My fear is this becomes a case of 'fix it for module A, break it for module B'.

[inglkruiz]

I understand, the situation is quite cumbersome. If you could list what packages you have tested I think I could try to make it work covering more cases and automating some tests. Just offering some help.