The server-side Node.js environment seems to have full access to modules, but the Lua env’ doesn’t even have require exposed.
OK, cool.
Lua modules are not remotely as well-defined a standard, the Lua package stuff won’t adhere to the system VFS or anything, and binary Lua modules (which comprises most of them) won’t work at all.
Unless you have a concrete proposal, this is more like a ‘nah’.
What exactly doesn’t adhere to the system VFS and why would C module “not work at all” compared to Node.js ? Lua C modules are dynamic libraries loaded via searcher/loader functions.
The fact that the package library just uses OS stuff directly, and not any of the resource path abstraction?
Node.js C modules also don’t work for similar reasons to Lua C modules not working.
Cool.
They still won’t work, won’t be platform-independent (Windows, all 100 varieties of Linux distros, different CPU architectures, etc.), and have I already mentioned they won’t work as they’re not standardized ABI/API-wise at all, let alone the build steps?
Quoting whoever maintains our Lua runtime now:
And many (C/C++ specific) Lua modules aren’t particularly well-defined for Windows & Linux.
LuaFS, for example, doesn’t support wstrings or offer anytype of additional *code support.
In theory, I wouldn’t be opposed to something like LuaRocks integration, but if you simply expose
requireESX and VRP will eventually just lead to forcing people to use precompiled binaries
In addition to that, is there anything you can’t do right now that would 100% need Lua C modules (not even just plain Lua modules, which you of course didn’t specify in your initial request that you meant C modules) to be possible?
Damn, the way you express yourself and the confidence… I just don’t have time for this.
At least this post will give input for other people looking into that kind of feature.
1 Like