Skip to content

Conversation

@asteurer
Copy link
Contributor

For clarity, I prefer to house the wit_* files in a shared directory.

@ricochet You had mentioned that you might like to move the wit directory in go-modules to componentize-go and store the wit_* files there. I'm worried about confusion arising from mixing new code with legacy code. I figured that it would be clearer to people that the wit_* files are associated with wit-bindgen if we organize them as such. I'm definitely open to discussion, so let me know what you think 😃.

Note: I relied on an LLM's suggestions for how to handle moving the wit_* files into the wit-bindgen directory. It's entirely possible that the docs/wit-bindgen setup isn't going to work haha

@asteurer asteurer requested a review from ricochet January 29, 2026 23:16
Signed-off-by: Andrew Steurer <94206073+asteurer@users.noreply.github.com>
@ricochet
Copy link
Contributor

Oh you know I hadn't actually considered moving wit. I was more concerned about any go referenced from the root for go-modules. My main advice is that since you aren't the legacy tool, you should pick the preferred package names.

One option to consider, place public api's in pkg, e.g. go.bytecodealliance.org/pkg. Most go projects aim for shorter names where they can. Looking at the current structure, the most idiomatic package names in my opinion would be:

  • go.bytecodealliance.org/pkg/wit/types
  • go.bytecodealliance.org/pkg/wit/async
  • go.bytecodealliance.org/pkg/wit/runtime

vs go.bytecodealliance.org/wit-bindgen/wit_types with inconsistent hyphen/underscores.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants