I agree with what you said -- although the node/npm ecosystem is much bigger. I'm not sure how it works with the nginScript subset.
But network-related libraries shouldn't be pulled from luarocks (unless maybe they have resty in the name). One would want to use lua-resty-redis and not hiredis within OpenResty. The 'resty' libs use the nginx cosocket library so work asyncronously with nginx core. hiredis would block the worker threads.
Ah thanks, I was not aware of that. Also, unless they code nginscript to specifically support googles V8 api, there's no reason to expect node or any of it's packages to work with it.
Not asynchronously, but in a non-blocking fashion. Good thing is that Lua socket and ngx.tcp are quite compatible. But C libs with their own IO not - well they work, but they will block the nginx workers.
But network-related libraries shouldn't be pulled from luarocks (unless maybe they have resty in the name). One would want to use lua-resty-redis and not hiredis within OpenResty. The 'resty' libs use the nginx cosocket library so work asyncronously with nginx core. hiredis would block the worker threads.