is not currently implemented in SLua, and it'll be a while before it is. The compiler currently runs fully on the server, and there's no existing facilities we can hook into for pulling in another script's source and embedding it within another.

I believe some others have developed hacks that evaluate within their local build toolchain and do bundling like and friends might, and that's probably what you'll have to do until we figure out what makes sense here. Failing that, you can use a local C preprocessor and just continue using . Definitely feel the development pain around having to do that though, we'll get that seen to.

Harold Linden can we not use the objects inventory and use a version include/require that takes the script name and includes it at compile time? This will allow us to split our scripts into modules or a more OOP layout without requiring access to client side code

That's the idea, although there's dragons lurking there, so it will be a bit. In particular, the current script compiler has no concept of object inventory, so resolving a at compile-time is tricky. Handling the at runtime would be possible, but because then your script may block on loading the second asset and hurt script performance on reset, not to mention that you then can't tree shake the d script's code at compile-time to remove functions that the script will never use or do function call inlining.

We'll publish a more detailed write-up about our thoughts on what scripters need / want from along with the implementation considerations sometime soon.

Harold Linden i mean i know yall want to give us a proper debugger so i guess thats a good tome to revamp the compiler

Jamesp1989 Resident:

We actually already have support for interactive debugging in the compiler / VM!

It's mostly a matter of figuring out how to give people a UI that doesn't suck, and giving people different compilation "modes" without turning the script editor into a spaceship control panel. Naturally, there's a lot of data plumbing work to be done as well!

.slua perhaps?

Kadah Coba Maybe, if LL really wants to be different for the sake of being different. I personally would prefer if we could use the existing ecosystem of Lua/Luau extensions on Visual Studio Code without having to go through and manually add a new file association. But if it was configurable behind a debug setting that'd be fine and more flexible if there ends up being a huge library of tools.

FireTruck Siren:

Yeah, using as the file extension seems best to me so people can take advantage of the existing ecosystem.

Honestly, the only reason we decided against calling it Luau in the viewer is that we've made significant-enough changes to the VM that we were concerned we'd be accidentally violating Roblox's trademark by calling it Luau (see Sun Microsystems vs Microsoft.)

Harold Linden That is very reasonable. It's also somewhat helpful in deflecting a footgun for newbies who might look up Luau tutorials and get very confused by Roblox examples using APIs that don't exist in SLua