Skip to content

Conversation

@sebas5384
Copy link

@sebas5384 sebas5384 commented Nov 2, 2025

Problem

Implements a namespace deduplication for Convex API code generation. When organizing Convex functions (queries, mutations, actions) into separate files, the generated API namespace no longer duplicates the function name if it matches the filename and the file contains a single function.

Currently organizing a single function in a dedicated file would create redundant namespaces:

// File: convex/blog/post/getComments.ts
export const getComments = query(...)

// Generated namespace (BEFORE):
api.blog.post.getComments.getComments   (duplicated)

// Generated namespace (AFTER):
api.blog.post.getComments   (clean)

Benefits

🎯 Cleaner API Namespaces: Eliminates redundancy for the common pattern of single-function-per-file organization
🛡️ Safe: Zero breaking changes - only affects new single-function-per-file pattern

Issue related: #102 (comment)

@nipunn1313
Copy link
Collaborator

I don't believe this is backwards compatible. Can't take this PR since it's making some fundamental changes to the API interface, but the input is taken. The function call syntax can be verbose in files with a single function. (CC @ianmacartney / @thomasballinger )

Would recommend you use default exports in the meantime.

@nipunn1313 nipunn1313 closed this Nov 2, 2025
@sebas5384
Copy link
Author

hey @nipunn1313 thanks for looking into this PR, could you tell me more what fundamental changes are you referring to? I'll use the default export

@sebas5384
Copy link
Author

sebas5384 commented Nov 3, 2025

@nipunn1313 just tested using the default export and it adds a "default" at the end.

Is there a way of avoiding this? I could work on something to at least remove the default last part?

@nipunn1313
Copy link
Collaborator

you're welcome to fork the library if you want.

It's just that the change is not easy to do backwards compatibly, so we're unlikely to roll it out incrementally like this. Perhaps something like it could be rolled into a larger v2.0 release of an API - but would want our team to think about it.

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