For the record, this is not true. I was asking for this awhile back, and you gave me the same uninspiring response. Typescript-ref and similar class names, different namescape - Clients / TypeScript - ServiceStack Customer Forums
My use case is simple and similar. We have a bunch of Features we want to plug into a single API project. Each feature has its own service models / interfaces, and while running 1 API per 1 Feature separately they are fine, when running multiple features in a single API they can run into the same conflicts described above.
It would be awesome if you could produce a logical work-around that fixes this issue we are experiencing-- to have a way to plug in multiple features and service stack take care of ensuring that each service model/interface is auto-mapped to ensure no duplication of type names.
Thus allowing the metadata / openapi / auto-gen service clients dtos to all get wired up correctly so that when using the serviceclient’s / dtos it hits the API and routes to the correct feature’s service implantation.
It could be as simple as adding the feature name to the pattern and ensuring the mappings get wired up, and as @grexican pointed out, can be optional configuration to wire it up.
appHost.LoadPlugin(new SomeFeature()).WithPrefix(nameof(SomeFeature));
appHost.LoadPlugin(new SomeFeature()).WithDefaultPrefix();
Then when generating the dtos / metadata code Account would become SomeFeatureAccount. It’s url would be prefixed with /SomeFeature/ and it allows for the dev teams to work without needing to be aware of this current limitation.
I hope you reconsider your opiniated position, as there are valid use cases out here and your current position leaves a gap in your product. You don’t see it, but it’s there and now I know I’m not the only one to come across it. A lot of friction that could be reduced if only you saw the value in doing so-- even if it was just for this use case.
Thank-you for your time and attention to this matter.