Cross-runtime compatibility.
So you can write a package which works across any runtime
1 Like
You can’t do require(“ModuleScript”) to get a child ModuleScript?
2 Likes
What’s this even supposed to mean lol, isn’t there only one runtime? Does that mean using multiple threads? I feel so stupid LMAO
nope. this is not something you can do.
1 Like
Not sure how this update helps? If I have module scripts in ReplicatedStorage or ServerScriptStorage for example and need to require them, this update does not allow me to do that with just strings? I will still have to have a reference to the folder in which the module scripts reside. The only use case seems to be the very limited hierarchy structure provided in the details which I don’t think I’ve ever used.
If anything I would have loved to see the ability to export and import modules globally instead of by string or reference. It feels funny to use other languages all day and then hop on Roblox and have to do this EVERY single time I want to use a module.
local ModulesFolder = game:GetService("ReplicatedStorage").ExampleFolder
local myRequiredModule = require(ModulesFolder.MyModule)
7 Likes
How’d you even manage to figure that out, it wasn’t listed in the post. Also, doesn’t a single dot mean sibling? Wouldn’t you have to use 2 dots?
We’re getting into stuff that doesn’t impact Roblox directly, but impacts people who write code on and off of Roblox.
Essentially, Luau as a programming language is meant to be ‘embedded’. This means that e.g. Roblox can take it, put it in their engine, and then change it however they want. This is in fact how Roblox does things.
However, other people can do that, and they do. To name an obvious example, Remedy Entertainment (the developers of Alan Wake) use Luau in their engine.
We call each of the environments that embed Luau a ‘runtime’; essentially it just means a place where Luau runs.
There are some Roblox devs who want to write code that will run both in Roblox and in other engines. This is a step towards allowing them to do that, because now Roblox supports the thing that other runtimes do.
3 Likes
Yeah this. As a tangible example, Fusion is looking to run in non-Roblox environments right now. We previously introduced a bunch of abstraction layers to help with this, but one thing we haven’t been able to do was change how require() works because it’d lose all the built-in autocomplete.
With require-by-string, I’m hoping to finally make meaningful progress towards using Fusion in other runtimes like Lune without using a bundler. I hope this can help make Fusion much more accessible to much more people and used for more cool things into the future! (I may or may not be thinking about bundling it with a certain voxel engine I’ve been hacking away on over on Bluesky…)
It probably makes less sense if you’re strictly on Roblox though.
9 Likes
script is used as the entry point.
entry point reference??
3 Likes
no, this is not an entry point reference??
1 Like
This feature was announced in other places long before this post, it’s even been implemented into studio for the past two months.
1 Like
require("/ScriptName")
I believe.
What you’re looking for is what the rest of us have meant by “aliases”. In standalone Luau’s require-by-string, you can define aliases that are essentially shortcuts for string requires.
Hypothetically, you could have one like this:
ModulesFolder = game.ReplicatedStorage.ExampleFolder
And then you’d do requires like
local myRequiredModule = require("@ModulesFolder/MyModule")
However you can’t actually do that, and the ability to set aliases doesn’t exist in this release. For some reason.
1 Like
Tested this out, it sadly doesn’t work.
2 Likes
Thank you, this works just fine.
1 Like
Fantastic addition. I’ve waited for this for ages. I would love to see this system genericised into jQuery style selectors too for anything in the game. Also, the game.Loaded workaround is a bit tiresome and I would love some shorthand for it, or a property, or maybe even a require function that waits.
For those who don’t want to wait for aliases support (to write something like require("@pkg/my-package") or deal with inconsistencies, darklua has been supporting require by string for a long time now! It’s able to convert those into Roblox instance paths.
During that year and a half, I published around 50 packages and some are already compatible outside of Roblox Luau.
It’s free if you want to check it out: GitHub - seaofvoices/darklua: A command line tool that transforms Lua code
If you have questions about darklua, there is darklua project thread in the Roblox open-source discord 
7 Likes
Unfortunately, I won’t be able to use this for most of my projects; my personal framework currently relies on requiring ModuleScripts housed directly as children, and I can not reasonably accommodate using string requires given I’d need the really ugly ./{parentScriptName}/{childScript} syntax. Not only does this just make it really hard to figure out what script is actually being required (since one would expect not needing to jump to the parent), but it requires me to update my requires any time the parent name may change; extra maintenance work that isn’t needed with the ModuleScript instance syntax.
I understand that this was potentially done to match non-Roblox luau, which can just near-instantly error if the script isn’t present on the file system however writing boilerplate at the top of every script which requires another one doesn’t look very nice either. Requiring by ModuleScript was sort of the same. Essentially, you’d just throw WaitForChilds inside the require call (of course only when necessary); however, that is just how instances work, so it makes sense. Ideally, for string requiring, we’d have some new alternative to do the waiting for us.
Luau + Roblox compatability is a complex task. There are such vast differences between the two to the point that both need to be considered together rather than prioritising one and porting to the other. Otherwise, we end up with un-ideal syntax like this. I do like to personally think of luau and Roblox luau as essentially different languages since even while there is mostly feature parity and the same general syntax; a user of one is not necessarily a user of the other.
Obviously, efforts should still be made to ensure syntax remains the same between the two. However, it is also worth noting that what works in one syntax may not necessarily be ideal for the other, and modifications may need to be made to one to make it more ideal for the other. I know this is an ‘in hindsight’ argument since luau had string requires long before Roblox luau got them. However, I do think it is necessary to bring up for any future potential changes.
1 Like
Yeah, this can help me with my libraries if it requires modules.
1 Like