Skip to content

docs: reposition around Lua 5.1 interop rather than general scripting - #12

Merged
mschmicking merged 1 commit into
masterfrom
docs-positioning
Aug 8, 2026
Merged

docs: reposition around Lua 5.1 interop rather than general scripting#12
mschmicking merged 1 commit into
masterfrom
docs-positioning

Conversation

@mschmicking

Copy link
Copy Markdown
Owner

The README led with "embed Lua 5.1 in your Node.js programs" — which invites a comparison this package loses:

fengari          6,562,808 /mo   pure JS, no compiler
wasmoon            117,044 /mo   WASM, no compiler
node-lua-runner         40 /mo   compiles from source

But that is the wrong comparison. You reach for this when you need Lua 5.1 exactly — to interoperate with a runtime you don't control (firmware, Redis scripting, OpenResty, game modding) — or when you need Lua to touch the real filesystem and run real processes. No no-compile alternative can do either: they target a different Lua version and run sandboxed.

Changes

  • Leads with the interop use case and names the ecosystems that are on 5.1, so someone searching for that problem can recognise it.
  • Adds an honest "Is this the right package?" section that names wasmoon and fengari, quotes their own descriptions, and says plainly to use them when the Lua version doesn't matter. Sending the wrong users away costs nothing; the right ones can now find themselves.
  • Documents the LuaJIT distinction. This is stock PUC-Rio Lua 5.1.5. Source and C API compatibility with a LuaJIT target are fine, but precompiled bytecode is not interchangeable. Anyone doing firmware interop needs to know that before depending on it.
  • Notes that Node-API is ABI-stable across Electron as well as Node, which is what makes this usable in a VS Code extension without rebuilding per host release.
  • Adds the untrusted-code warning to Caveats — the full stdlib including os.execute is the point of the package, and that has an obvious implication.
  • npm description and keywords updated to match, since that is what shows in search results.

I deliberately did not assert version numbers for wasmoon or fengari — I could not verify those from the registry, so the table describes their approach in their own words and leaves the version claim as "a newer Lua than 5.1".

Verified

  • README 100 → 137 lines, all local links and anchors resolve
  • package.json still at 2.0.1 (release-please's bump untouched)
  • Tarball guard passes: 67 files, 29 vendored Lua sources

🤖 Generated with Claude Code

The README led with 'embed Lua 5.1 in your Node.js programs', which invites a
comparison against wasmoon and fengari that this package loses: both need no
C++ toolchain, and requiring one is a real barrier.

That comparison is also the wrong one. The reason to reach for this is that you
need Lua 5.1 *exactly* -- to interoperate with a runtime you do not control,
such as firmware, Redis scripting or OpenResty -- or that you need real
filesystem and process access rather than a sandbox. No no-compile alternative
can offer either, because they target a different Lua version and run
sandboxed.

Adds an honest 'is this the right package?' section that names those
alternatives and says plainly when to prefer them. Sending the wrong users away
costs nothing; the right ones can now recognise their problem.

Also documents that this is stock PUC-Rio Lua 5.1.5 and not LuaJIT, so
precompiled bytecode is not interchangeable with a LuaJIT target -- source and
C API compatibility are unaffected. And records that Node-API is ABI-stable
across Electron as well as Node, which is what makes the addon usable inside a
VS Code extension without rebuilding per host release.

npm description and keywords updated to match, since that is what appears in
search results.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@mschmicking
mschmicking merged commit edf0a9e into master Aug 8, 2026
13 checks passed
@mschmicking
mschmicking deleted the docs-positioning branch August 8, 2026 10:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant