Add shared Lua library modules
Extend external library packages so multiple UI addons and provider packages can share lazily loaded Lua modules as well as images. Intended outcome: - Library packages may declare a bounded module root alongside or instead of an asset root. - Consumers explicitly declare the library with `<Requires package="…" />`. - `ui.require("package.id/module")` loads a declared module from that library into the consuming package's existing Lua VM. - Each consuming VM caches its own module result; no mutable state, callbacks or function handles cross package boundaries. Constraints: - Library code never executes automatically; modules load only through `ui.require`. - Preserve instruction, memory, source-text and module-count budgets. - Refuse undeclared dependencies, traversal, symlinks, duplicate module names and cyclic module loads. - Keep bundled Core modules and package-local module definitions working unchanged. - Preserve Native AOT compatibility and package failure containment. Verified outcome: - Library manifests accept `<Modules root="lua" />` alongside or instead of `<Assets>`. - Lowercase module paths are namespaced as `library.id/path` and wrapped as lazy `ui.define` factories before consumer scripts run. - `ui.require` caches module results per consuming VM; tests verify two consumers do not share mutable module state. - Library module trees are bounded and refuse non-Lua files, traversal, symbolic links, oversized files and excessive module counts. - Libraries remain non-executing until required, cannot have entry scripts or dependencies, and preserve existing cycle and definition checks. - Full client tests and the native Lua sanitizer/generator and Native AOT suite pass. Pull request: #2973 https://git.project-rk.com/prk/engines/pulls/2973
Checklist
0 of 0 completeNo checklist items.
- Area
- Project Rubi-Ka
- Project
- engines
- Kind
- Feature
- Priority
- Medium
- Task ID
tsk_2k7n4ckrky- Updated