RFC: Support Luau-syntax configuration files

[vrn-sn]

Rendered

[jackdotink]

Looks pretty great. My bikeshed is that .luauconfig as a name is fine but I'd rather have .config.luau so that syntax highlighting just works and there's no need for more editor and especially github configuration.

[vrn-sn]

I've renamed .luauconfig to .config.luau in this RFC, and I've now split the section about the timeout into analysis-time and runtime subsections.

For runtime configuration, I've introduced a new LUAUCONFIG_RUNTIME_TIMEOUT_SECONDS macro to override the default runtime timeout of two seconds.

[JohnnyMorganz]

Is it 2 seconds per config file (my current understanding), or 2 seconds overall for config resolution? Given that the directory hierarchy matters and we'll potentially be extracting a config from every ancestor directory.

[vrn-sn]

I'm kind of going back and forth. My original intention was per-file, but now am unsure about a design that causes a linearly scaling hang time wrt. virtual filesystem depth.

At runtime, there's only one use case, which looks like this with a cumulative timeout: every time we see an alias in require, we attempt to resolve it by executing each VFS node's .config.luau (going up the ancestry chain as needed). If we reach the timeout limit while executing a .config.luau in the chain, we throw a timeout error.

That seems okay to me. Ultimately, the timeout is a protective feature—I'd expect that extracting information from .config.luau would be trivial in almost all cases.

[jackdotink]

There are a few ideas I'll toss out that I think could make this better.

• Change from camel case to lowercase. It's really a nit but it would be more consistent with the rest of Luau and this is probably the only opportunity that will exist to do this.
• Place Luau configuration inside a luau field. This would enable other tools to store their own configuration in these files, and provide the precedent that such configuration should be under its own field. Think of a tool like a Luau optimizing compiler or a linter like Selene - having directory specific configuration can be quite useful. In Roblox the same could apply for plugins.
• Allow for these files to be required at runtime. In the same vein as the previous suggestion, it would be useful for tools written in Luau to be able to easily access these configuration files without needing to load the file and then plop it into loadstring. I can see this being useful especially for Roblox plugins. These requires would almost always be dynamic, so maybe there is a better solution for Luau tooling being able to access Luau config.
• Set the timeout to be really low. It can always be increased in the future and it's not like these files have access to any interesting APIs at the moment. It exists as a protective feature, but I cannot see a .config.luau file doing a computation of any kind. Setting the timeout really low would also encourage other tools to not encourage users do do computations in these files. I would recommend a timeout of 0.1 to 0.2 seconds.

[jackdotink]

I think that to remain consistent with other similar cases with require, this should be ambiguous and error.

[aatxe]

Seems fine.

[alexmccord]

You could add a special case in Frontend to add a constraint on the module's return type to be LuauConfig like below. This enables autocomplete for free.

[alexmccord]

Ditto.

[vegorov-rbx]

• Set the timeout to be really low.

I think this is a bad idea. Small interrupts on a machine will cause builds to be flaky.

• Allow for these files to be required at runtime.

This is best left to a separate proposal explaining the exact runtime semantics.
There's no need to overcomplicate the simple move from existing configuration files in this RFC.

[aatxe]

• Change from camel case to lowercase. It's really a nit but it would be more consistent with the rest of Luau and this is probably the only opportunity that will exist to do this.
• Place Luau configuration inside a luau field. This would enable other tools to store their own configuration in these files, and provide the precedent that such configuration should be under its own field. Think of a tool like a Luau optimizing compiler or a linter like Selene - having directory specific configuration can be quite useful. In Roblox the same could apply for plugins.

These two are good calls IMO, and we should integrate both.