module … not found error when the all‑in‑one loader is omitted in Lua 5.4

Answer to the core question

In Lua 5.4 the package.searchers table is built by the core. The optional all‑in‑one loader is a C function that concatenates the error strings of the individual loaders and returns a single module … not found message. Whether this loader is present depends on how the interpreter was compiled:

• Default build – the configure script adds the loader to package.searchers after the standard Lua and C loaders.
• Custom or minimal builds – the flag --disable-all-in-one-loader (or a similar configuration option in the build system) removes it. Some embedded distributions replace it with a custom loader that mimics its behaviour but does not expose the same debug signature.

When the loader is omitted, each individual loader still runs. If they all fail, Lua concatenates the error fragments it received from the Lua loader, the C loader, and any user‑added loaders. The final error string is therefore shorter and its fragments appear in the order of the remaining loaders. The generic “module … not found” text that the all‑in‑one loader supplies is missing, so the message may look like module 'foo' not found: no field package.preload['foo'] or a similar chain of fragments.

Detecting the loader’s presence at runtime

A reliable check does not rely on the final error string. Instead, inspect package.searchers for a C function whose debug source string matches the internal name used by the built‑in loader (typically luaopen_module). The following snippet demonstrates the test:

local function has_all_in_one_loader()
  for _, loader in ipairs(package.searchers) do
    if type(loader) == "function" then
      local info = debug.getinfo(loader)
      if info and info.source == "@luaopen_module" then
        return true
      end
    end
  end
  return false
end

print("All‑in‑one loader present:", has_all_in_one_loader())

Key points:

• Run the check before adding or removing loaders at runtime.
• If the interpreter was built with stripped debug information, debug.getinfo may return nil for C functions, and the check will report absence even though the loader exists.
• Custom builds that replace the loader with a user‑defined C function may share the same source string, leading to a false positive. In such cases, compare the function’s address or the number of entries in package.searchers against the expected default count (usually 3: Lua, C, all‑in‑one).

What to do if you need a uniform error message

Because the final error string is implementation‑defined, you cannot rely on it for automated diagnostics. Instead, catch the error and examine the stack field of the error object or use the detection function above to decide whether to prepend your own message.

Missing diagnostic detail

Do you have debug.getinfo available in your build, or is the binary stripped? This determines whether the source string check will work reliably.