Yeah it was an easy fix, it just caught me off guard. It only affected one script out of hundreds, so it’s a pretty rare edge case. I don’t expect anyone else will be affected.
So if ModuleB at the end of the hierarchy was swapped out with ModuleC after runtime, ModuleA would error upon requiring ModuleC when it expected ModuleB, but only if it ModuleC’s type definitions are different from ModuleB? This could work, but only if the type definitions were generated while the developer is coding and be saved somewhere in the script’s data, so that the time the types are evaluated isn’t arbitrary.
The confusing part would be assigning the assumed module type definitions to actual variables (requires) in the code. Some sort of special using or require header that pairs automatic type definitions with how that dependency is required/loaded would be simplest, although it does still have design challenges.
Type data could be associated with a specific unique variable assignment. The simplest solution would be to define all dependencies/requires in a header, and it would be as simple as processing the header to get a module’s external dependencies. Similar to this (ignore the exact syntax):
using
Foo = require(script.Parent.Class)
Bar = _G.req("Framework")The types of Foo and Bar could be stored in a property separate from .Source.
These are just ideas. Explicit typing needs explicit requiring, and there isn’t really an obvious solution that fulfills the scalability (lazy replication) problem without using a very involved preprocessor.
In my system, for example, the scripts that show the map Gui only replicate with their dependencies when the player opens the map tab, and the script that runs a dragon’s logic only replicates when a dragon near the character is also replicated. This extends to non-script data as well, but it’s enormously valuable when attempting to create a truly massive MMO that remains lightweight on the client with fast join times.