Allow .config.luau to require other .config.luaus

[PhoenixWhitefire]

Rendered.

[Bottersnike]

To what degree does this solve the machine-writing problem? Is it just an assumed/given that tooling will need to do one of:

• Own the initial generation of the .config.luau file, or
• Prompt the user to update their .config.luau with the required modifications to include the tooling-managed file

?

---

Calls to require may use aliases defined by ancestral configuration files.

This feels like it could get messy fast, and could be mildly confusing semantics "why can all other files in this folder use this alias, but this one specific file can only use aliases defined elsewhere?". I can somewhat see the utility though.

---

What happens if hina.config.lua exists but not hina.config.luau? Do we now support .config.lua or are require-by-string semantics different in this regard when in a .config.luau file?

---

Given .luaurc files are safely machine writable for purposes like described in the motivation, this feature feels like it could deliver a lot more benefits from the

Allow any Luau module to be imported

alternative. If some requires are allowed in .config.luau, allowing all requires opens the doors for properly dynamic configurations (set @foo to ./foo-y on platform X but ./foo-y on platform Y, for example). This does come with its own set of drawbacks (quite a few) but it feels a little strange to only half-add requires for something that's not a problem when just using .luaurc.

[PhoenixWhitefire]

To what degree does this solve the machine-writing problem? Is it just an assumed/given that tooling will need to do one of:

• Own the initial generation of the .config.luau file, or
• Prompt the user to update their .config.luau with the required modifications to include the tooling-managed file

?

Maybe I shouldn't have given Package Managers as much focus as I did, but I believe if this was implemented then they could do either of those things. I think a package manager user would prefer the latter, that keeps more control with them.

This feels like it could get messy fast, and could be mildly confusing semantics "why can all other files in this folder use this alias, but this one specific file can only use aliases defined elsewhere?". I can somewhat see the utility though.

The intent was to clarify that it is impossible for a config to do the following:

-- Using `@myAlias`, but it's also defining it
local something = require("@myAlias/foo")
-- `@earlier` is defined in a config before us
local otherThing = require("@earlier/bar")

return {
    luau = {
        aliases = {
            something = something.alias,
            myAlias = "../../myAlias",
        }
    }
}

At the point of the require call being executed, the module is still being evaluated as a configuration and there's no way for the alias to be registered at that point. The only aliases that are possible to use are ones that are guaranteed to be defined before this config runs.

What happens if hina.config.lua exists but not hina.config.luau? Do we now support .config.lua or are require-by-string semantics different in this regard when in a .config.luau file?

After some thinking, I have updated RFC to specify it will have the same behavior in terms of mapping modules to actual files - i.e. hina.config -> hina.config.lua(u), hina.config/init.lua(u), for consistency with the existing require semantics. .config.luau, exactly, will continue being the only entry point.

---

I do think supporting use cases like the platform-dependent alias you described can be interesting and useful, but it does raise a lot more questions and it feels like it might be more than I'm willing to take on for this RFC. How would it determine the target platform? Would it be run through a CLI where a platform argument is provided? Would it need to read a file? How does that work with LSPs? Maybe that can instead be a sort of build system, one that generates configuration files - and I think this feature would make that easier to do for .config.luaus. It only needs to generate a file that returns a table of aliases, and that can be imported into the root configuration.

[deviaze]

This would increase RBS complexity for basically no real gain. Very few embedders support the full RBS spec anyway atm, and this would just add another thing to worry about when implementing or otherwise discussing RBS semantics.