This is not intended behavior, and a fix will be in shortly—thank you for flagging it! An exported function (a closure) is expected to capture its environment, including the context from which require-by-string is resolved.
In the meantime, I wouldn’t recommend relying on the current behavior. If you’d like the correct behavior right now, I’d recommend performing the actual require-by-string call outside of the closure, storing the result in a variable, and referring to it inside the closure using the variable:
-- For now, keep outside of closure
local result = require("../Folder/ModuleScript")
local function DoSomethingWithModule()
print(result)
end
return DoSomethingWithModule
Can we get support for instances containing “/” in their names?
If we have this instance hierarchy: Folder: “Routes” > ModuleScript: “10/12”, calling require("./Routes/10/12") from a ModuleScript placed inside “Routes” Folder crashes with error Unable to require module from given path './Routes/10/21'. If we place another Instance inside the ModuleScript “10/12”, it is not recognised by the autofill of the string path expression, however the instance “10/12” itself is shown during typing. I understand this might be harder to resolve but it is not unrealistic, right?
I think it’s unlikely that we will support requiring instances with / in their names, as / is unambiguously meant to be a directory separator for require-by-string. I am filing a ticket about autocomplete, though—we shouldn’t be showing autocomplete suggestions for these invalid Instance names. Thanks for bringing this up!
I would expect them to perform similarly. While avoiding performance regressions matters too, the main motivation for this change was cross-runtime compatibility.
I agree, we should be able to do require("child") or require("/child") for both consistency and convenience. Require-by-String is already faster to write than manually indexing for siblings, but there is currently no reason to use it for children.
Yeah, that makes sense. But now looking at Introducing Require-by-String - #126 by sleitnick reply, could it maybe get supported with escape characters? (like require("./Routes/10\/12")) If not, that’s also fine.
I know it would probably be considered bad practice but if you are to rename the roblox engine classes eg → "ReplicatedStorage" to "CustomName" it seems to break the auto completion and typechecking
though you can still access the path using the under the hood classname eg → require("../../ReplicatedStorage/Modules/CoolModule") with proper auto completion and typechecking past the "ReplicatedStorage/" segment even when it’s renamed to "CustomName/"?
Curious if there will be support for renamed engine classes? as it currently throws a 'CustomName' is not a valid Service name error
Although the require("./{script}/child") syntax is technically legal, it definitely isn’t ideal and isn’t really what simple relative paths are meant for in require-by-string. We haven’t gone into it in this post, but we will be releasing @self soon and pointing to it as the preferred approach (e.g. require("@self/child").
