Hello! I’m trying to create a module that holds a list of locations of other modules. For example:
Directory Module:
local Directory = {}
Directory.PlayerManager = script.Parent
return Directory
However, when trying to require the paths I get a type error saying ‘Unknown require: unsupported path.’ even though at runtime this should work perfectly fine.
Script:
Is this a bug? I noticed that this also happens with ObjectValues as well.
I believe it’s just a type checking error you shouldn’t worry about. Is the script.Parent a moduleScript?
yes the script.parent is a module script.
Its just annoying to see the type error when everything is working perfectly fine.
Ignore it. I think it’s bugging you because you are trying to require a module in a already returned dictionary. It will still work, but I think your structure is sort of wrong.
Usually if you have a main module (the highest of the hierachy), you require everything below it inside that main module, and so on for the sub-descendants of the children.
I suggest you learn OOP, it’s relatively easy and will give you better knowledge on how to structure modules.
Already familiar with OOP. Just wanted to create a directory module so its easy to change the location of the modules and its assets. The reason I put them in separate module from the main module was to make it more readable.
Why is having a directory module considered a bad structure?
It’s not a bug, but rather an intentional design of the strict type-checker. The type-checker will only analyze and import types from modules that can be statically resolved.
It is just the type-checker throwing a fit, so you can just cast the result to any if you really want to do things this way, but you won’t have access to the types contained within the module unless you require the ModuleScript directly.
Dang, I really want to use type checking. Really wish there was a way to tell the type checker that the stuff inside this directory module is static.
Since this is an intentional design of the type checker, does this mean that having a directory module is considered bad practice?
There’s nothing wrong with the structure inherently, and it was kind of the schtick behind Knit and other legacy frameworks. It works and was more convenient at the time, but the addition of a more powerful linter to Studio kind of upended that. Unless using another IDE that provides “intellisence-like” utility while supporting the structure, giving up auto-complete, type-checking, etc. to reduce boilerplate code at the top of modules usually isn’t worth the trade.
There’s nothing wrong with the modules, it’s just how you require it. You’re requiring the main module inside a module that is under it. Rather than indexing modules inside a module, then requiring that module inside the module, it’s just better to just require the modules individually and independently inside your main script.
And if you were requiring inside a module, you require everything that is a children of it, and in those children you require the children and so on, not the reverse. It’s so much better because then you don’t have conflicts (e.g requiring the same module multiple times in different locations; requiring a module and then making changes to it won’t change the actual module itself).
