You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One of the limitations of the current approach to creating standalone apps is that the runtime only requires and loads the entry point (as mentioned in the documentation). It's not difficult to extract files, but I didn't want to port the old import builtin as it has some issues, and luvit's approach of overriding require is even worse. The result is that you can't just require a module that's present in the archive, and any file that was loaded from disk would have to be extracted manually (which makes for a poor UX).
Obviously this feature is quite desirable, but I've put off adding it until I found a simple solution that "just works".
For the first part of the problem (loading Lua scripts), I believe there exists an elegant solution for a custom module loader:
By adding a new searcher, custom module loading logic can easily be added to the require system
If the runtime registers one that looks into the virtual file system of the LUAZIP archive, it can trivially require any Lua file
The only question is whether the searcher should take precedence over reading files from disk
Argument for reading from VFS before disk: Makes sure the built app loads the right module if there's name clashes
Argument for reading from disk before VFS: Allows overriding behavior without a rebuild, although it may be accidental
Due to security concerns and because building is fast anyway, I tend towards reading from the VFS first
I made a quick prototype and there's no issues preventing this to be implemented, things seemed to work as expected:
One of the limitations of the current approach to creating standalone apps is that the runtime only requires and loads the entry point (as mentioned in the documentation). It's not difficult to extract files, but I didn't want to port the old
import
builtin as it has some issues, and luvit's approach of overridingrequire
is even worse. The result is that you can't justrequire
a module that's present in the archive, and any file that was loaded from disk would have to be extracted manually (which makes for a poor UX).Obviously this feature is quite desirable, but I've put off adding it until I found a simple solution that "just works".
For the first part of the problem (loading Lua scripts), I believe there exists an elegant solution for a custom module loader:
require
systemLUAZIP
archive, it can triviallyrequire
any Lua fileI made a quick prototype and there's no issues preventing this to be implemented, things seemed to work as expected:
The text was updated successfully, but these errors were encountered: