This seems somewhat useful but honestly I was hoping for the alias paths (assuming we can set global strings to reference certain modules used a lot?). I also prefer starting at the root (usually ReplicatedStorage) and working my way down.
local Tween = require(ReplicatedStorage.Modules.Shared.Tween)
local Tween = require("Tween")
Still neat though, can’t wait until we get these!!
Pretty much like all of theses free models admin system work. a loader that requires a modulescript directly uploaded on the toolbox. but unlike these modules as far as i know packages can be made private?
yeah, alias paths are typically something similar to that. except in the luau implementation, it would be more like require("@tween")
sort of, simplest roblox terms is a modulescript that you can download and insert into your game. it would not be a loader though, it would just be the code itself
It seems premature to release this without aliases, and it is a bit disappointing that the ongoing plans for it is still in the dark for the rest of us. There doesn’t seem to be any use cases for this in its current state, and while I understand it is a big first step, announcing it on the Roblox DevForum carries some expectations that were not met today.
It’s very long and in the Roblox open source Discord server. I’m not sure Roblox would be too happy with me linking a Discord server on a public announcement though, so I won’t link it here.
The TL;DR is that there’s no way forward that doesn’t break compatibility with someone. It was either Rojo, Luau’s existing require-by-string semantics, or both. The discussion boiled down to:
foo/init.luau changes shape when synced by Rojo (it becomes a ModuleScript named foo)foo become invalid when synced (requiring ./bar doesn’t work anymore because bar is now a child, not a sibling)There are a few RFCs you can read on the subject (amended require resolution for init file, Amended Require Syntax, and Absolute Require Syntax but they don’t really cover the full thing. Though that’s a good thing: it was ultimately somewhere in the ballpark of 8 hours of discussion.
Thank you roblox 
Parent.Parent.Parent days are OVER
The main issue is that Rojo changes the shape of things!
Consider this structure:
If you want to require submodule.luau from init.luau, on the file system it’s require("./submodule").
However, when they’re synced into Roblox with Rojo, they look like this:
To require submodule from from module (which used to be init.luau), you need to do require("./module/submodule"). Beyond being bad semantically, it’s also clearly different.
There were a couple solutions thrown out. I was in favor of changing requires to be more akin to web urls, but that’s not really important now because they didn’t go for it. Instead they went with the solution that a bunch of community members felt very strongly against without changing it even slightly despite getting a lot of feedback and alternative suggestions, and now it’s released so we can’t change it.
Rojo isn’t planning on adding a toggle because we’re very tired of cleaning up Roblox’s mistakes, especially unforced ones. If ‘just add a toggle’ is an acceptable solution for Rojo, there’s no incentive for them to ever consider us when making decision.
Hey - wanted to put in my two cents here,
I asked the representative from the team working on this feature in the OSS server for special care to be taken regarding the implementation of RBS (require-by-string) module aliasing. I don’t mean to make anyone pivot super hard, I’m just stating my highest level priority here – I’d appreciate it if the focus on project-relative requires was instead put to aliasing.
I understand and do value the fact that Roblox and the team are working to reduce friction across runtimes - I’ve experienced the friction that’ll be alleviated with this change in some of my projects, and it’ll be a great help. But project-relative requires (if I correctly understand what that term means) are just not valuable to my Studio workflow right now. Project-relative requires are not something that’s blocking.
On the other hand, we need that aliasing so that our engineers can have the intellisense delivered to them in our RBS workspaces via plugin. Aliasing, if done right, would be a force multiplier for the company I work at.
Thanks
Seems unneeded and pointless but whatever. Systems like this pair better with something like Godot’s scene based game engine, not Roblox.
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”