feat(sdk): add addons to javascript SDK#2833
Conversation
📝 Walkthrough## Walkthrough
This change introduces two new classes, `Addons` and `SubscriptionAddons`, to the JavaScript API client, providing typed methods for managing addon and subscription addon resources via HTTP API calls. The `OpenMeter` class is updated to expose these new classes as public properties, enabling direct access to their respective methods.
## Changes
| File(s) | Change Summary |
|------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| api/client/javascript/src/client/addons.ts | Introduced a new exported `Addons` class, providing typed async methods for CRUD and lifecycle operations on addons, including `create`, `list`, `get`, `update`, `delete`, `publish`, and `archive`. All methods use a generic API client and transform responses for consistency. |
| api/client/javascript/src/client/subscription-addons.ts | Added a new exported `SubscriptionAddons` class with async methods to create, list, get, and update subscription addons. Each method uses path parameters, strong typing, and response transformation for API interactions. |
| api/client/javascript/src/client/index.ts | Updated the `OpenMeter` class to include two new public properties: `addons` (instance of `Addons`) and `subscriptionAddons` (instance of `SubscriptionAddons`). Added necessary imports and instantiated these classes in the constructor. No other logic was changed. |
| api/client/javascript/package.json | Bumped multiple development dependencies including ESLint packages, TypeScript, React types, testing tools, and code formatters. Upgraded "openapi-fetch" from 0.13.5 to 0.14.0. Added a new "onlyBuiltDependencies" array under "pnpm" config listing "esbuild" and "unrs-resolver" as build-only dependencies. No changes to scripts or main entries. |
| api/client/javascript/src/portal/index.ts | Consolidated import statements by combining separate imports of `createClient` and `createQuerySerializer` from 'openapi-fetch' into a single import statement without changing functionality. |Note ⚡️ AI Code Reviews for VS Code, Cursor, WindsurfCodeRabbit now has a plugin for VS Code, Cursor and Windsurf. This brings AI code reviews directly in the code editor. Each commit is reviewed immediately, finding bugs before the PR is raised. Seamless context handoff to your AI code agent ensures that you can easily incorporate review feedback. Note ⚡️ Faster reviews with cachingCodeRabbit now supports caching for code and dependencies, helping speed up reviews. This means quicker feedback, reduced wait times, and a smoother review experience overall. Cached data is encrypted and stored securely. This feature will be automatically enabled for all accounts on May 16th. To opt out, configure 📜 Recent review detailsConfiguration used: CodeRabbit UI ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (2)
✅ Files skipped from review due to trivial changes (2)
⏰ Context from checks skipped due to timeout of 90000ms (11)
✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
api/client/javascript/src/client/addon.ts(1 hunks)api/client/javascript/src/client/index.ts(6 hunks)api/client/javascript/src/client/subscription-addon.ts(1 hunks)
🧰 Additional context used
🧬 Code Graph Analysis (3)
api/client/javascript/src/client/index.ts (2)
api/client/javascript/src/client/addon.ts (1)
Addons(6-161)api/client/javascript/src/client/subscription-addon.ts (1)
SubscriptionAddons(6-114)
api/client/javascript/src/client/addon.ts (3)
api/client/javascript/src/client/schemas.ts (1)
paths(1-2056)api/client/javascript/src/client/common.ts (1)
RequestOptions(6-6)api/client/javascript/src/client/utils.ts (1)
transformResponse(15-35)
api/client/javascript/src/client/subscription-addon.ts (3)
api/client/javascript/src/client/schemas.ts (1)
paths(1-2056)api/client/javascript/src/client/common.ts (1)
RequestOptions(6-6)api/client/javascript/src/client/utils.ts (1)
transformResponse(15-35)
🪛 Biome (1.9.4)
api/client/javascript/src/client/addon.ts
[error] 110-110: void is confusing inside a union type.
Unsafe fix: Use undefined instead.
(lint/suspicious/noConfusingVoidType)
⏰ Context from checks skipped due to timeout of 90000ms (11)
- GitHub Check: E2E
- GitHub Check: CI
- GitHub Check: Quickstart
- GitHub Check: Lint
- GitHub Check: Developer environment
- GitHub Check: Commit hooks
- GitHub Check: Test
- GitHub Check: Migration Checks
- GitHub Check: Build
- GitHub Check: Analyze (javascript)
- GitHub Check: Analyze (go)
🔇 Additional comments (15)
api/client/javascript/src/client/addon.ts (7)
6-8: LGTM! Class implementation follows the client pattern.The
Addonsclass constructor correctly accepts and stores the client instance, following the same pattern as other service classes in the codebase.
9-28: LGTM! Create method implementation looks good.The create method is properly implemented with appropriate typing, parameter handling, and response transformation.
30-49: LGTM! List method is correctly implemented.The list method correctly handles optional query parameters and request options, with proper type definitions for parameters and return values.
51-70: LGTM! Get method follows established patterns.The get method properly accepts an addonId parameter and optional request options, following the established pattern in the codebase.
72-94: LGTM! Update method is properly implemented.The update method correctly accepts addonId, addon data, and optional request options with appropriate type definitions.
120-139: LGTM! Publish method is correctly implemented.The publish method correctly accepts addonId and optional request options, with proper type definitions for parameters and return values.
141-160: LGTM! Archive method follows established patterns.The archive method properly accepts an addonId parameter and optional request options, following the established pattern in the codebase.
api/client/javascript/src/client/index.ts (3)
6-6: LGTM! Imports are properly organized.The imports for the new
AddonsandSubscriptionAddonsclasses are correctly added and maintained in alphabetical order.Also applies to: 20-20
51-51: LGTM! New properties are properly declared.The new public properties
addonsandsubscriptionAddonsare correctly declared with their respective types, maintaining alphabetical order with existing properties.Also applies to: 65-65
88-88: LGTM! Properties initialization is correctly implemented.The
addonsandsubscriptionAddonsproperties are properly initialized in the constructor, maintaining the same pattern as other service classes and alphabetical order.Also applies to: 102-102
api/client/javascript/src/client/subscription-addon.ts (5)
6-8: LGTM! Class implementation follows the client pattern.The
SubscriptionAddonsclass constructor correctly accepts and stores the client instance, following the same pattern as other service classes in the codebase.
9-34: LGTM! Create method implementation looks good.The create method is properly implemented with appropriate typing for all parameters, proper path parameter handling, and response transformation.
36-58: LGTM! List method is correctly implemented.The list method properly accepts a subscriptionId parameter and optional request options, with proper type definitions for parameters and return values.
60-84: LGTM! Get method follows established patterns.The get method correctly handles path parameters for both the subscription ID and subscription addon ID, following the established pattern in the codebase.
86-113: LGTM! Update method is properly implemented.The update method correctly uses PATCH (instead of PUT used in the Addons class), which is consistent with the API endpoint definition in the schemas.
tothandras
force-pushed
the
galexi/addons-js-client
branch
from
10a2dcd to
3286d28
Compare
tothandras
changed the title
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (5)
api/client/javascript/src/client/addons.ts (5)
6-7: Constructor looks good, but consider adding a type for client paths.The generic client parameter with template literal type works well. For better maintainability, consider defining a type alias for
${string}/${string}to make its purpose clearer.
30-32: Consider adding explicit return type for better clarity.While TypeScript can infer the return type, explicitly defining it would improve documentation and maintainability.
public async list( params?: operations['listAddons']['parameters']['query'], options?: RequestOptions - ) { + ): Promise<ReturnType<typeof transformResponse>> {
64-67: Simplify the verbose type declaration for better readability.The type for the addon parameter is quite verbose. Consider creating a type alias for this complex type to improve code readability.
+type AddonUpdateData = operations['updateAddon']['requestBody']['content']['application/json']; public async update( addonId: string, - addon: operations['updateAddon']['requestBody']['content']['application/json'], + addon: AddonUpdateData, options?: RequestOptions ) {
78-83: Improve return type documentation for delete method.While other methods clearly document what entity is returned, the delete method mentions "void or standard error response structure". Consider making the documentation consistent across all methods or explicitly mentioning the return type for all methods.
6-122: Consider adding error handling or documenting error patterns.While the
transformResponseutility likely handles errors, there's no explicit error handling in the methods. Consider either:
- Adding try/catch blocks for more explicit error handling
- Documenting the error handling pattern in class-level JSDoc
- Ensuring consistent error responses across all methods
This would make the API more predictable for consumers.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
api/client/javascript/src/client/addons.ts(1 hunks)api/client/javascript/src/client/index.ts(6 hunks)api/client/javascript/src/client/subscription-addon.ts(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
- api/client/javascript/src/client/index.ts
- api/client/javascript/src/client/subscription-addon.ts
⏰ Context from checks skipped due to timeout of 90000ms (13)
- GitHub Check: Artifacts / Container image
- GitHub Check: Artifacts / Benthos Collector Container image
- GitHub Check: Test
- GitHub Check: Quickstart
- GitHub Check: Migration Checks
- GitHub Check: Lint
- GitHub Check: E2E
- GitHub Check: Developer environment
- GitHub Check: CI
- GitHub Check: Commit hooks
- GitHub Check: Build
- GitHub Check: Analyze (javascript)
- GitHub Check: Analyze (go)
🔇 Additional comments (3)
api/client/javascript/src/client/addons.ts (3)
1-5: Imports look appropriate.The imports include necessary utilities and types for the Addons client implementation. Good use of explicit types from the OpenAPI schema.
9-22: Create method implementation is clean and well-documented.Good use of JSDoc comments and proper parameter typing. The method correctly passes the addon object in the request body.
1-122: Overall implementation is clean and follows consistent patterns.The Addons class is well-structured with consistent method implementations for CRUD operations and additional lifecycle actions (publish, archive). Each method is well-documented and follows the same pattern of making an API request and transforming the response.
tothandras
force-pushed
the
galexi/addons-js-client
branch
from
3286d28 to
d6fa331
Compare
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
api/client/javascript/src/client/subscription-addons.ts (1)
6-99: Consider implementing a delete method for subscription addons.The class implements create, read, and update operations but appears to be missing a delete operation. If the API supports deleting subscription addons, consider adding a
deletemethod to complete the CRUD operations./** * Delete a subscription addon * @param subscriptionId - The ID of the subscription * @param subscriptionAddonId - The ID of the subscription addon to delete * @param options - Optional request options * @returns The operation result */ public async delete( subscriptionId: string, subscriptionAddonId: string, options?: RequestOptions ) { const resp = await this.client.DELETE( '/api/v1/subscriptions/{subscriptionId}/addons/{subscriptionAddonId}', { params: { path: { subscriptionAddonId, subscriptionId } }, ...options, } ) return transformResponse(resp) }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
api/client/javascript/src/client/addons.ts(1 hunks)api/client/javascript/src/client/index.ts(6 hunks)api/client/javascript/src/client/subscription-addons.ts(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
- api/client/javascript/src/client/index.ts
- api/client/javascript/src/client/addons.ts
⏰ Context from checks skipped due to timeout of 90000ms (11)
- GitHub Check: Quickstart
- GitHub Check: E2E
- GitHub Check: CI
- GitHub Check: Test
- GitHub Check: Migration Checks
- GitHub Check: Lint
- GitHub Check: Developer environment
- GitHub Check: Build
- GitHub Check: Commit hooks
- GitHub Check: Analyze (javascript)
- GitHub Check: Analyze (go)
🔇 Additional comments (7)
api/client/javascript/src/client/subscription-addons.ts (7)
1-5: LGTM: Appropriate imports for functionality.The imports correctly include all necessary utilities and types for implementing the subscription addons functionality.
6-8: LGTM: Class structure follows the existing pattern.The
SubscriptionAddonsclass constructor correctly takes a typed client parameter following the pattern used in other client classes.
9-31: LGTM: Well-implemented create method with proper typing.The create method is properly implemented with:
- Clear JSDoc documentation
- Strong typing for parameters
- Correct HTTP method (POST)
- Proper path parameter handling
- Response transformation
33-49: LGTM: Well-implemented list method.The list method correctly implements the GET operation with appropriate parameter handling and response transformation.
51-72: LGTM: Well-implemented get method.The get method correctly retrieves a specific subscription addon by ID with proper path parameter handling.
74-98: LGTM: Well-implemented update method.The update method correctly implements the PATCH operation with appropriate parameter handling.
1-99:Details
✅ Verification successful
Verify error handling strategy.
The code relies on
transformResponsefor handling API responses, but there's no explicit error handling in the methods. Please verify thattransformResponseproperly handles error cases, or consider adding explicit error handling if needed.
🏁 Script executed:
#!/bin/bash # Check the implementation of transformResponse to understand error handling cat api/client/javascript/src/client/utils.js | grep -A 20 "transformResponse"Length of output: 152
Let’s locate and inspect the actual
transformResponseimplementation to confirm its error handling:
🏁 Script executed:
#!/bin/bash # Locate and show the implementation of transformResponse rg -n "transformResponse" -A 20Length of output: 72759
Error Handling Verified
The
transformResponsefunction (api/client/javascript/src/client/utils.ts lines 24–27) already throws anHTTPErrorforresp.erroror status codes ≥ 400, so all client methods will propagate errors appropriately. No additional error handling is needed in theSubscriptionAddonsmethods.
2 participants
Overview
As the title says
Notes for reviewer
Summary by CodeRabbit