Tested this out, it sadly doesn’t work.
3 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.
1 Like
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 
10 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.
5 Likes
Yeah, this can help me with my libraries if it requires modules.
2 Likes
Honestly, it should just default to the current script if no dots are placed, that would actually make it faster since you could technically type just require("childScript"). I don’t know if this isn’t possible for whatever reason but it would be way more convenient.
No clue why they would purposefully make it less convenient than script.childScript but like whatever
1 Like
6 Likes
Wait… doesn’t the single dot mean sibling?
2 Likes
Wow, never thought I’d see the day. Thank god we can use relative paths now.
Only took like what? 18 years?
1 Like
I’m starting to think that NPM is going to follow me everywhere. I’m not really a fan of this. I get why its useful and the purpose but, it takes away clarity as to where those paths (from alias) derive from.
A bit scared as to how Roblox would implement this if they chose that route.
3 Likes
bro this is crazy update for the roblox IDE, i love it!!11
1 Like
this is better for us, thanks!
1 Like
was this a beta feature before? because I was able to require modules by strings for a long time and it marked type errors with strict mode, but it didn’t autocomplete like it’s now which is a great thing
1 Like
meh addition. at first, i was under the impression that you could use global references
also for anyone who has module scripts scattered around and don’t want the hassle of typing the full path to them, might as well assign tags for your module scripts and use CollectionService to retrieve. i’m using this approach when i’m editing someone’s messy workspace
3 Likes
didn’t know you could use do that, i always use CollectionService not in it’s intended purpose, merely just to run server code on the client (i.e script that usually runs a infinite loop to change a few properties of an object)
1 Like
This feature is AMAZING I am so excited to use this omg
1 Like
Unironically dot requires are better when string requires were ment to be a fix. 
Because at least i can just type script and not the scripts name.
5 Likes
no it was a unannounced thing like how one could use the new audio api stuff before it was announced, albeit this time it only worked in studio
1 Like