You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While we namespace objects in graphql and in client codegen, in the go sdk codegen is all in the same package so if you want to name a type "Container" your code won't compile, even though it's gonna be namespaced later anyways.
This may also cause problems in the introduction of a new core type could create conflicts with existing modules and thus break them.
In terms of fixes:
We should skip namespacing if an object already has the namespace applied. Eg if a module named cool has a type called CoolContainer, we don't need to renamespace and call it CoolCoolContainer
That's probably worth doing no matter what and partially solves the problem, but it doesn't fix the issue of new core types breaking existing modules.
To solve that, we may need to just move the client codegen to a subpackage rather than be in the same. This is fraught as we need to ensure that always importing the correct codegen package is as seamless as possible.
Another option is to make core as versioned and modular as all other modules, but that's a fairly large project (though one we want in the long term anyways)
The text was updated successfully, but these errors were encountered:
While we namespace objects in graphql and in client codegen, in the go sdk codegen is all in the same package so if you want to name a type "Container" your code won't compile, even though it's gonna be namespaced later anyways.
This may also cause problems in the introduction of a new core type could create conflicts with existing modules and thus break them.
In terms of fixes:
That's probably worth doing no matter what and partially solves the problem, but it doesn't fix the issue of new core types breaking existing modules.
To solve that, we may need to just move the client codegen to a subpackage rather than be in the same. This is fraught as we need to ensure that always importing the correct codegen package is as seamless as possible.
Another option is to make core as versioned and modular as all other modules, but that's a fairly large project (though one we want in the long term anyways)
The text was updated successfully, but these errors were encountered: