Since the addition of RunContext, I’ve used ReplicatedStorage similarly, for self contained systems that involve both the server and the client. I’ve even written some ModuleScripts designed to work on both the client and the server
Here,
Chests and Settings are client and server sided. Backpack is client sided only(InventoryModule could just be a folder tbh)
This method has the main advantage of keeping systems contained under a single instance, instead of being spread out into multiple containers, making the organization of a game neater and making it easier to move systems from one game to another (which is great for Resources > Community Resources modules)
The suggestion is interesting, but imo, not necessary. It is easy enough to have a RunService:IsServer() (or IsClient) assert at the top of the script. I am also unsure if the security concern is that big of a deal. Don’t quote me on that, but according to this thread, clients only receive the bytecode rather than the source code, meaning they would have to decompile the bytecode to have something readable (and decompiled code is usually rough). If you don’t have RemoteEvent snooping checks, it might be easier for an exploiter to send garbage data through your remotes to find vulnerabilities instead of decompiling the code and reading it
I personally would be more concerned about exploiters stealing the game’s code than finding vulnerabilities. More of my code is ending up inside of ReplicatedStorage, (even my datastore module is in ReplicatedStorage), meaning an exploiter using a save instance exploit has a much bigger portion of the game
(Don’t ask me how they can save instance scripts if they don’t have access to the source code. Do they really create clone games from decompiled code?)
That would indeed be really useful. I’ve had to do some workarounds because of this
A RunContext property for ModuleScripts could be a nice QoL addition, for explorer icons and making it clear which module can be called by the client/server. Security would be another benefit
although I wouldn’t call it RunContext as module scripts don’t run by themselves, perhaps AllowedContext or something along those lines would be better