Roblox’s Luau and its type checking bring amazing features and a lot of good changes over Lua for developers and makes the language a lot more mature and potentially feature-rich. However…
As a Roblox developer, it is currently too hard to achieve proper type checking with the weakness of existing module references in luau code. For example, if I stored a module like in the following psuedo-code:
--!strict
local myModulesHolder = {
modules = {};
};
function myModulesHolder:IncludeModule(Module)
self.modules[Module.Name] = Module;
end
function myModulesHolder:GetModule(Name)
return require(self.modules[Name]);
end
return myModulesHolder;
…then I ran :IncludeModule on some module in 1 script and tried to :GetModule(Name) on that named module in another script within the same RunContext, it would result in type errors and undesirable behavior (namely the “Unknown require: unsupported path” type error, or result in a nondescript generic type included by developers type casting GetModule). Why shouldn’t Luau know about the module I stored with :IncludeModule(), by name?
If Roblox is able to address this issue, it would improve my development experience because I would be empowered to create extremely powerful and dynamic frameworks which allow me to visually see methods and properties of my own proprietary “service” objects, and any other arbitrary storing of references to module scripts in Luau would theoretically be natively type checked even with deep references far from the source of where that module script may have been initially stored.
Opening modules to check the methods, not being able to use autocomplete or “intellisense”, and various other issues related to this are all major sources of slowdown in my workflow. Type security is extremely important for competent programmers, especially those working on teams where, the more I as a programmer know about the intention another programmer had when writing code, the better. I know this is not a simple issue, but this problem is one of several key issues that is keeping Roblox Studio weaker and less competitive when looking at industry standards for game engines. A more serious IDE with more support for developers to build powerful code bases and frameworks that make our lives easier, and safer, would instantly relieve a lot of pressure and make programmers on Roblox a lot happier. Especially when a feature like this would empower teams of programmers, where communication and intent is absolutely vital.
Most competent programmers would simply say to just use module scripts and use require() to circumvent this issue, and while that is a valid solution, which I myself have employed, it causes us to lose out on other powerful features (such as lifetime service functions and much simpler module management), and makes the process of writing boilerplate more cumbersome. Additionally, modules bear the same potential issues as the children-property dilemma, where a future Roblox update creating a new property could possibly ruin instance hierarchy naming schemes and create issues on latest versions.
Ceding developers the control over how we include dependencies into our code is necessary. Forcing developers into using require() and module script instance paths creates unnecessary boxes around development and stifles the ability of developers to create dynamic frameworks and libraries that make making games easier.
To wrap this all up, I will state this: Creating a more robust module reference linter/type checker for Roblox Studio and Luau is essential for moving Roblox Studio into a more industry standard state. As a Roblox Developer, I am also aware that many of my colleagues favor third party tooling such as the “Rojo” plugin, which has it’s own host of issues that slow down development. I am aware that Roblox is developing their own tool to allow third party IDEs, but those tools are problematic for most developers and we feel as though if Roblox Studio itself were more powerful natively, we wouldn’t need to consider tools allowing third party IDE integration. Swapping between multiple windows is a net slowdown in exchange for the added benefit of some plugins and better intellisense adding some speed. It also backpedals on some of Roblox’s core ideals, by creating more barriers for new developers, in turn making it harder to learn how to make games with Roblox Studio.
I envision a development style where we only have to boot up 1 program to do everything, because I think Roblox Studio has the potential to be a super powerful tool. Adding this feature would be a massive step towards shaping it into the program we all want it to be, a powerful piece of software that is literally paving the future of games.