@samarvir I can reproduce the problem. It turns out NODE_PATH never worked.
handlebarsonly seemed to work because handlebars was already part of n8n!
OK, on investigation what I found is:
- n8n uses vm2 to run code.
- vm2 in turn uses node's built-in vm module.
- However, vm2 does not use NODE_PATH - https://github.com/patriksimek/vm2/blob/master/lib/sandbox.js#L250 . So, the solution that I had earlier is wrong. It just happened to work for handlebars and some other random modules I tried.
All this means that we can only use the modules in
Since jsonata seems generally useful, I have included it in the package itself. Let me know if you need other node modules and I can add them.
robi last edited by
@girish why not link it over?
@robi each module brings it's own set of dependencies. So, we have lots of folder of symlink taking into account somehow that they might conflict with upstream's node dependencies. npm usually sorts this all out keeping directory structure flat and gives each module it's own copy when modules conflict, very hard to just symlink.
robi last edited by
@girish there has to be a higher pivot point where individual symlinking isn't necessary, no?
like all of node_modules/
NODE_PATHworks. It's an additional path where system wide node_modules can be found. But it doesn't work with the
Symlinking all of node_modules essentially means copying over all the code to a writable location and installing user modules on application startup. We might as well run the app from
/app/dataat this point. Generally, we don't do this in Cloudron unless there is no other way and we cannot live without it.
robi last edited by robi
@girish I see.
looking at vm2 there are ways to specify modules by relative paths in the script.
Ctrl-f on "Loading modules by relative path"
Here it mentions using NODE_EXECUTABLE
@robi correct, vm2 can be made to load them but n8n does not configure it that way. I guess this has to be reported upstream to n8n to support loading modules outside node_modules.