Timeline for mlua `0.11`

[filiptibell]

Hello!

I was wondering if there is some kind of timeline for when a full release of mlua 0.11 will be made?
I see there have been 3 beta releases so far, and no rc. I would really like to use require-by-string and latest Luau version in Lune to properly fix issues such as 311 and 327 without depending on beta or rc versions - to be able to also release a full 0.10 version for Lune.

[khvzak]

I would say it's almost ready, I'm testing the latest version in some real tasks and as soon I confirm it works okay, I'll cut the release (likely next week).

[khvzak]

Also would be really helpful if you try the new version, as after 0.11 I cannot make even minor breaking changes.

[filiptibell]

Also would be really helpful if you try the new version, as after 0.11 I cannot make even minor breaking changes.

Will do! I am trying it right now and after some very small changes it compiles and the Lune test suite all passes fine. I am running into some issues with registering modules like:

lua.register_module("@lune/modulename", ...)?;

It seems like it does not support this type of nested path registration by default. Do I need to make a custom require resolver using the new trait or is this feasible for mlua to add?

[cheesycod]

Also would be really helpful if you try the new version, as after 0.11 I cannot make even minor breaking changes.

Will do! I am trying it right now and after some very small changes it compiles and the Lune test suite all passes fine. I am running into some issues with registering modules like:

lua.register_module("@lune/modulename", ...)?;
It seems like it does not support this type of nested path registration by default. Do I need to make a custom require resolver using the new trait or is this feasible for mlua to add?

What’s the issue here. I do this and it works just fine?

[filiptibell]

I am running into some issues with registering modules like:
lua.register_module("@lune/modulename", ...)?;
It seems like it does not support this type of nested path registration by default. Do I need to make a custom require resolver using the new trait or is this feasible for mlua to add?

What’s the issue here. I do this and it works just fine?

It is not working in Lune. Every single require in our tests throws an error like:

error requiring module "@lune/datetime": could not reset to requiring context

Here's the PR and example test failure:

• Upgrade to mlua 0.11 lune-org/lune#328
• https://github.com/lune-org/lune/actions/runs/15898499174/job/44835697382?pr=328

---

EDIT: I haven't managed to make a minimal repro, yet.. this and anything similar works as expected:

lua.register_module("@foo/bar")?;
lua
    .load("print(require('@foo/bar'))")
    .set_name("=test")
    .exec_async()
    .await?;

[khvzak]

@filiptibell I don't think the function inject_std is even called during Runtime initialization.

[khvzak]

On the other note, the .set_name("=test") likely will prevent requiring any physical Lua file on disk.

Luau "require" uses chunk name to reset context to find current "location". You will get error require is not supported in this context for unsupported chunk names.
mlua currently has logic to reset locaiton to the current directory for chunks that named like "@something.rs" (which includes autogenerated names).

[filiptibell]

@filiptibell I don't think the function inject_std is even called during Runtime initialization.

Oops, yeah you are correct. I forgot to push a change with that. The same "could not reset to requiring context" error still happens though, except now it is not on the entire test suite & every require with @lune/.... Check this run: https://github.com/lune-org/lune/actions/runs/15902180080/job/44847588827

[khvzak]

@filiptibell
With the following patch:

--- a/crates/lune/src/rt/runtime.rs
+++ b/crates/lune/src/rt/runtime.rs
@@ -216,7 +216,7 @@ impl Runtime {
         script_path: impl AsRef<str>,
         script_contents: impl AsRef<[u8]>,
     ) -> RuntimeResult<RuntimeReturnValues> {
-        let script_name = format!("@{}", script_path.as_ref());
+        let script_name = format!("@{}", script_path.as_ref().strip_suffix(".luau").unwrap());
         self.run(script_name, script_contents).await
     }

most of the tests will pass.

chunk names should not have .lua or .luau suffix. At least in the Luau CLI canonical implementation they add them to chunk names to get real path (expecting it's not present already)

I'm not sure if this is right behaviour (implemented at Roblox) and I can modify mlua to support both cases (with or without .lua(u) suffix)

[filiptibell]

With the following patch most of the tests will pass.

I'm not sure if this is right behaviour

@khvzak Thank you, this worked! I also think it is correct behavior after thinking about it for a bit. Require by string should only care about "module" paths and not file extensions or even if there is a filesystem at all. Maybe it is worth putting this in mlua documentation to guide users better but I think the behavior itself is correct.

There is only one more require test failing now which I believe should succeed:

local task = require("@lune/task")

local module1
local module2

task.defer(function()
	module2 = require("./modules/async")
end)

task.spawn(function()
	module1 = require("./modules/async")
end)

task.wait(1)

-- ... some assertions about the module contents ...

assert(module1 == module2, "Required modules should point to the same return value")

It fails on the module1 == module2 assertion.
The module that it resolves to has these contents:

local task = require("@lune/task")

task.wait(0.25)

return {
	Foo = "Bar",
	Hello = "World",
}

So, it runs require on the same final file twice concurrently, and that file sleeps for 0.25 seconds. The previous require implementation in Lune has a lock & broadcast channel to ensure that a module can only be required exactly once, even if async. This is necessary to prevent any side effects that may happen from calling require on a file where it may be using fs, net, etc. Here is a failing run: https://github.com/lune-org/lune/actions/runs/15906579794/job/44863012103

[khvzak]

@filiptibell
The module result is cached only after being fully executed, which makes sense. Doing any yielding in the module code and re-executing the module again should give different result.

If Lune wants custom behaviour with locking and broadcasting, it can be done by implementing Require trait with custom logic.

It's quite exotic use case, the vanilla Luau does not even support yielding in modules (it fails with module can not yield error).

[filiptibell]

@khvzak
I have started implementing a custom require resolver using the Require trait - and I managed to get everything working the same as mlua TextRequirer, as well as the custom lock & broadcast behavior, however requires that use the @self alias seem broken and it is unclear why. I was hoping you could take a look.

With this example file structure:

directory
-> subdirectory
---> init.luau
---> module.luau

And these contents in the init.luau file:

require("@self/module")

It seems that it calls to_parent indefinitely, until reaching filesystem root, which is very strange. All other requires work perfectly and do not do this, only the self alias ones. Here are the relevant links:

• Require implementation
• Real test file
• Failing test run

And here is a stack trace (dunno how useful this is):

tried to require a module at the filesystem root
[Stack Begin]
    Script '[C]' - function 'proxyrequire'
    Script '__mlua_require', Line 13
    Script '/Users/.../lune/tests/require/tests/modules/self_alias', Line 1
    Script '__mlua_require', Line 22
    Script '/Users/.../lune/tests/require/tests/init_files', Line 12
[Stack End]

[rhit-sashiks]

@khvzak I have started implementing a custom require resolver using the Require trait - and I managed to get everything working the same as mlua TextRequirer, as well as the custom lock & broadcast behavior, however requires that use the @self alias seem broken and it is unclear why. I was hoping you could take a look.

With this example file structure:

directory
-> subdirectory
---> init.luau
---> module.luau

And these contents in the init.luau file:

require("@self/module")
It seems that it calls to_parent indefinitely, until reaching filesystem root, which is very strange. All other requires work perfectly and do not do this, only the self alias ones. Here are the relevant links:

• Require implementation
• Real test file
• Failing test run

And here is a stack trace (dunno how useful this is):

tried to require a module at the filesystem root
[Stack Begin]
    Script '[C]' - function 'proxyrequire'
    Script '__mlua_require', Line 13
    Script '/Users/.../lune/tests/require/tests/modules/self_alias', Line 1
    Script '__mlua_require', Line 22
    Script '/Users/.../lune/tests/require/tests/init_files', Line 12
[Stack End]

I haven't delved into your code yet but this looks like a bug in your Require implementation as the test you gave works with my require resolver. To be really honest, I'd recommend looking at Lute to see how they did their Require implementation since the way they structured it is really nice. Another example require impl which passes your self_alias thing: https://github.com/Anti-Raid/khronos/tree/master/crates/runtime/src/require.

From a cursory glance though, your to_parent method looks a bit suspicious as I am pretty sure init.luau self requires might pop past the filesystem root due to RBS (I worked around this personally by having a / path that descends down to an empty path).

Personally, here's what I did for to_parent in case it helps

pub fn to_parent(&mut self) -> Result<NavigationStatus, crate::Error> {
        log::trace!("AbsModPath: {}", self.absolute_module_path);

        if self.absolute_module_path.is_empty() {
            return Ok(NavigationStatus::NotFound);
        }

        // DEVIATION: Allow "" as a parent view to root dir
        if self.absolute_module_path == "/" {
            self.module_path = "".to_string();
            self.absolute_module_path = "".to_string();
            log::trace!("Deviation: set module_path + abs_module_path to empty");
            return self.update_real_paths();
        }

        let mut num_slashes = 0;
        for c in self.absolute_module_path.chars() {
            if c == '/' {
                num_slashes += 1;
            }
        }

        if num_slashes <= 0 {
            return Err("num_slashes <= 0".into());
        }

        if num_slashes == 1 {
            self.module_path = "".to_string();
            self.absolute_module_path = "".to_string();
            return self.update_real_paths();
        }

        self.module_path = normalize_path(&PathBuf::from(self.module_path.clone() + "/..")).to_string_lossy().to_string();
        log::trace!("NewModPath: {}", self.module_path);
        self.absolute_module_path = normalize_path(&PathBuf::from(self.absolute_module_path.clone() + "/..")).to_string_lossy().to_string();
        log::trace!("NewAbsModPath: {}", self.absolute_module_path);
        self.update_real_paths()

[filiptibell]

Okay, I figured out the issue. This was quite confusing since it seems the reference implementations I looked at other than mlua (above + lute) reset to an empty path when encountering "/", and then afterwards get the correct to_parent return value as a side effect, on the subsequent to_parent call, or when some fs call inevitably fails on the empty path.

The reference TextRequirer implementation in mlua does it correctly and straightforward:

mlua/src/luau/require.rs

Lines 241 to 257 in 2595589

	fn to_parent(&mut self) -> StdResult<(), NavigateError> {
	let mut abs_path = self.abs_path.clone();
	if !abs_path.pop() {
	return Err(NavigateError::NotFound);
	}
	let mut rel_parent = self.rel_path.clone();
	rel_parent.pop();
	let module_path = Self::find_module(&abs_path)?;
	self.abs_path = abs_path;
	self.rel_path = Self::normalize_path(&rel_parent);
	self.module_path = module_path;
	Ok(())
	}

Lune had a similar implementation. The last important detail here as to why Lune was not working, is that it has to be exactly the NotFound error, and Lune was using a custom error message instead. I have left a comment for future readers in lune-org/lune@8bfdfac .

I think with this resolved it completes the migration for Lune to mlua 0.11 and we are able to use it whenever it is released without issues. @khvzak

[khvzak]

Thank you for confirming, I'll add some extra comments to the TextRequirer implementation.

Also as you may noticed, the TextRequirer is public (mlua::TextRequirer), so you probably can wrap around it and add custom logic to the loader function, keeping the navigation logic unchanged.