Skip to content

Conversation

@devin-ai-integration
Copy link
Contributor

Description

Refs: User request from @aditya-arolkar-swe

Adds clientClassName and exportedClientClassName config options to the TypeScript SDK generator, matching the C# generator functionality.

Devin Session: https://app.devin.ai/sessions/62307c91d1a7499b91d5f724ae7d9559

Changes Made

  • Added clientClassName and exportedClientClassName to TypescriptCustomConfigSchema
  • Added config fields to SdkCustomConfig interface
  • Implemented config parsing in SdkGeneratorCli
  • Passed config options through SdkGenerator.Config
  • Modified AbstractSdkClientClassDeclarationReferencer to accept and store config options
  • Updated SdkRootClientClassDeclarationReferencer to use custom names:
    • getExportedName(): Returns exportedClientClassName if set, falls back to clientClassName, then default
    • getClientClassName(): Returns clientClassName if set, falls back to default
  • Updated README.md generator (not applicable - config-only change)

Testing

  • Lint checks pass (pnpm run check)
  • Unit tests added/updated - NOT DONE
  • Manual testing completed - NOT DONE

Review Checklist

⚠️ Important items for reviewers:

  1. Incomplete implementation: This PR only adds the config plumbing and basic naming logic. The C# generator creates actual wrapper files when these configs are used. This implementation only changes the naming in the declaration referencer. Need to determine if wrapper file generation is required.

  2. Untested behavior: The following scenarios have not been tested:

    • Setting only clientClassName
    • Setting only exportedClientClassName
    • Setting both options
    • Backward compatibility when neither is set
  3. Missing updates: The following may need updates but were not modified:

    • Snippet generation (should use exportedClientClassName)
    • README generation (should use exportedClientClassName)
    • Any other code that references the client class name
  4. No tests: No unit or integration tests were added to verify the new functionality.

  5. Config validation: No validation that exportedClientClassName makes sense when clientClassName is not set.

Recommendation: This PR establishes the config infrastructure but may need additional work to fully match the C# generator's behavior. Consider whether this partial implementation is acceptable or if wrapper file generation should be added before merging.

Add support for clientClassName and exportedClientClassName config options
to the TypeScript SDK generator, matching the C# generator functionality.

- Add clientClassName and exportedClientClassName to TypescriptCustomConfigSchema
- Add config fields to SdkCustomConfig interface
- Parse config options in SdkGeneratorCli
- Pass config options through SdkGenerator.Config
- Implement client name customization in SdkRootClientClassDeclarationReferencer
- Add getClientClassName() method to distinguish between internal and exported names

This allows users to:
1. Customize the internal client class name via clientClassName
2. Customize the exported client class name via exportedClientClassName
3. Use different names for internal implementation vs public API

Co-Authored-By: [email protected] <[email protected]>
@devin-ai-integration
Copy link
Contributor Author

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

  • Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
  • Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

  • Disable automatic comment and CI monitoring

…sions.yml entry

- Add getClientClassName() method to properly separate internal and exported names
- Update SdkClientClassContextImpl to use internal class name for generation
- Add version 3.32.0 entry to versions.yml with feature documentation
- Ensure exported name is used for references while internal name is used for class declaration

Co-Authored-By: [email protected] <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

1 participant