When creating SDKs that are game independent, it is difficult to keep everything in one folder. I end up with a folder with all of the tools used by both the server and the client for convenience, but the downside of this is that the client can see all the server modules. The following is an example in ReplicatedStorage:
I suggest having an environment property on the folder so that the client cannot view the contents of these folders.
Does the ReplicatedStorage (client & server) and ServerStorage (server only) container system not work for you?
I understand you have an SDK organization setup in ReplicatedStorage, but you can achieve your goal by modifying it to store server-only contents in ServerStorage. I’m not sure this use case warrants the requested feature.
having to move those modules around is the problem because it’s all over the place, complicated and hard to keep up with.
i think you could combat this by making a surrogate or proxy for the Server modules so it’s easier to manage but i rather not have to do something like that
i agree with the op i want to store everything in one place with having the luxury of controlling what is being shared to the client
This is essentially another case of asking for control over replication which is a valid feature request and would be heavily desired. Server-only services that do not replicate contents to the client is already a strong feature but they’re hierarchically dependent. I absolutely support hierarchical independence from the question of “should this be replicated to the client?”.
It is possible to lock a set of items to the server by having the whole package in ServerStorage and hand-replicating anything that needs to be accessible to the client in a 1:1 repository in ReplicatedStorage then pointing some internal reference member to it or so but feels like it’d be significantly more use case universal and convenient to get control replication instead.
The real issue here seems to be that you can’t limit server source replication without sacrificing code organization. That should probably be the title of the request, rather than the proposed solution you are suggesting currently. (Remember, feature requests should focus on problems, not proposed solutions)