Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Go SDK Modules: Fix conflicts with core types #6071

Open
sipsma opened this issue Nov 6, 2023 · 0 comments
Open

Go SDK Modules: Fix conflicts with core types #6071

sipsma opened this issue Nov 6, 2023 · 0 comments

Comments

@sipsma
Copy link
Contributor

sipsma commented Nov 6, 2023

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:

  1. 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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants