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.