This probably won't resolve the issue, though it does fix up issues where the .graphql-generated folder is created in a dev environment, commit to git and then deployed to prod. We don't mention in dev docs that different obfuscation classes are used on different environments
I think there's near zero value in keeping the class name intact since it's an auto-generated class, and for debugging you can either swap out to another obfuscator (can do this in yml or by setting the DEBUG_SCHEMA env variable), or just search for the type name in file content comments e.g. // @type:Query.
The classname is better being more obfuscated locally for a better IDE experience IMO
Issue https://github.com/silverstripe/silverstripe-graphql/issues/500
This probably won't resolve the issue, though it does fix up issues where the .graphql-generated folder is created in a
devenvironment, commit to git and then deployed to prod. We don't mention in dev docs that different obfuscation classes are used on different environmentsI think there's near zero value in keeping the class name intact since it's an auto-generated class, and for debugging you can either swap out to another obfuscator (can do this in yml or by setting the DEBUG_SCHEMA env variable), or just search for the type name in file content comments e.g.
// @type:Query.The classname is better being more obfuscated locally for a better IDE experience IMO
Note - obfuscation was only ever intended to help the IDE experience, it's not at attempt at security https://github.com/silverstripe/silverstripe-graphql/issues/369