Fair enough, I do think they are explicitly and purposefully not supporting that structure with this addition, and instead favour using folders to organise modules.
I totally get the frustration and thanks for explaining. I’ve seen plenty first party Roblox modules use that kind of structure so it does seem odd to harshly abandon it, especially with raising it on the OSS side nice and early.
Would you guys be open to someone taking on the work of adding a toggle independently? I’m interested in making my current workflow compatible across both and don’t want to maintain a Rojo fork for just myself.
Darklua already exists which can do what you want if a quick solution is what you’re looking for.
I am in complete support of Rojo being opposed to implementing anything to clean up this mess that roblox has made. Concerns and feedback were brought up which delayed the announcement of this feature by two months, and in those two months no changes were made. This is not on Rojo to fix.
Oh that’s a good idea! I might still go for a native hack in Rojo for the time being though because I don’t want to use a bundler, but that’s a good shout.
Thank you. Someday maybe I can remove Nevermore’s loader component entirely. This isn’t quite here yet, but require by string is one of a few systems needed to do this.
To be blatantly clear: it’s not about the difficulty of it or the maintenance burden. I implemented the required change in the behavior in a manner of minutes as an experiment.
It’s about the blatant disregard that was shown here. There were multiple RFCs opened that would have resolved this, and over 8 hours worth of discussion on the issues. There was no push to release this, as it wasn’t announced. And yet despite this, Roblox released it in this state anyway.
There was no attempt made to fix the direct-child-require problem (script.Foo has no obvious equivalent), and they very deliberately didn’t change the behavior that prevented compatibility to begin with. Now since it’s released on Roblox, it cannot be fixed so we are stuck with this behavior. Forever.
I’m not going to fix the unforced mistake that multiple people warned the entire Luau team of. Sorry that this comes at the cost of your code, but it was Roblox that made the decision that got us here, not Rojo.
And we won’t have to sacrifice LSP features anymore!
Understood. I’ll keep the code to my fork then. Thanks for the response!
Thank you!!! This is SO much better. Great start on your future plans!
can ayone explain the point of ever using this, will it make module loaders easier to work with or something
to me it looks like the difference between typing “k” and “ok”
Cross-runtime compatibility.
So you can write a package which works across any runtime
You can’t do require(“ModuleScript”) to get a child ModuleScript?
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.
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)
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.
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.
script is used as the entry point.
entry point reference??
no, this is not an entry point reference??