Introducing Require-by-String

Thanks for explaining, I’ll keep an eye out for the fix then!

they tried adding support for rojo but didn’t do it right :sob:

Is using the string faster or slower than indexing the hierarchy yourself?

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?

1 Like

The autocomplete does not escape strings properly. E.g. if parts of the path have special characters or quotes, it fails to escape them.

e.g.:

1 Like

We’ve filed an internal ticket for this bug. Thanks for reporting!

1 Like

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!

1 Like

I would expect them to perform similarly. While avoiding performance regressions matters too, the main motivation for this change was cross-runtime compatibility.

1 Like

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.

Hello again! This fix has been rolled out.

1 Like

Niceee. Will give it a try tonight.

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