-
Notifications
You must be signed in to change notification settings - Fork 0
feat: add uploadPart method type definition #12
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
Conversation
Add uploadPart method for uploading a part in a multipart upload transaction: - UploadPartOptions interface with headers, mime, and disabledMD5 fields - UploadPartResult interface with name, etag, and res fields - Method signature supporting file path or File object with byte range (start, end) - Comprehensive type tests covering various usage scenarios 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
|
Note Other AI code review bot(s) detectedCodeRabbit has detected other AI code review bot(s) in this pull request and will avoid duplicating their findings in the review comments. This may lead to a less comprehensive review. WalkthroughAdds two public types (UploadPartOptions, UploadPartResult) and a new SimpleClient method signature Changes
Sequence Diagram(s)sequenceDiagram
autonumber
actor Client
participant SimpleClient
participant IObjectSimple
participant OSS as "Object Storage / HTTP"
Client->>SimpleClient: call uploadPart(name, uploadId, partNo, file, start, end, options)
SimpleClient->>IObjectSimple: uploadPart(...) (forward/implement)
IObjectSimple->>OSS: PUT/POST part data (with headers/mime/MD5)
OSS-->>IObjectSimple: 200 OK + etag / response
IObjectSimple-->>SimpleClient: UploadPartResult { name, etag, res }
SimpleClient-->>Client: Promise resolves UploadPartResult
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes
Suggested reviewers
Poem
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: CodeRabbit UI Review profile: CHILL Plan: Pro 📒 Files selected for processing (1)
🔇 Additional comments (3)
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. Comment |
Summary of ChangesHello @killagu, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request significantly enhances the type definitions for the client library by introducing a new Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code Review
This pull request introduces type definitions for a new uploadPart method, along with corresponding options and result interfaces, and adds comprehensive type tests. The changes are logical and well-implemented. My feedback focuses on improving type safety by replacing the use of any with a more specific type for the file parameter in the new method signature, which will make the API more robust and easier to use correctly.
| async uploadPart(name: string, uploadId: string, partNo: number, file: any, start: number, end: number, options?: UploadPartOptions): Promise<UploadPartResult> { | ||
| console.log(name, uploadId, partNo, file, start, end, options); | ||
| return {} as any; | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To maintain consistency with the suggested change in the IObjectSimple interface, the file parameter in this mock implementation of uploadPart should also be updated from any to string | Blob. This ensures the type tests accurately reflect and validate the updated interface.
async uploadPart(name: string, uploadId: string, partNo: number, file: string | Blob, start: number, end: number, options?: UploadPartOptions): Promise<UploadPartResult> {
console.log(name, uploadId, partNo, file, start, end, options);
return {} as any;
}
src/index.ts
Outdated
| /** | ||
| * Upload a part in a multipart upload transaction. | ||
| */ | ||
| uploadPart(name: string, uploadId: string, partNo: number, file: any, start: number, end: number, options?: UploadPartOptions): Promise<UploadPartResult>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The file parameter is currently typed as any, which bypasses TypeScript's type checking. To improve type safety and clearly define the contract of this method, it's better to use a more specific type. Based on the pull request description and tests, this parameter can be a file path (string) or a file-like object. I suggest using string | Blob, as the File type used in tests inherits from Blob. This makes the type definition more precise and self-documenting.
| uploadPart(name: string, uploadId: string, partNo: number, file: any, start: number, end: number, options?: UploadPartOptions): Promise<UploadPartResult>; | |
| uploadPart(name: string, uploadId: string, partNo: number, file: string | Blob, start: number, end: number, options?: UploadPartOptions): Promise<UploadPartResult>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Nitpick comments (1)
src/index.ts (1)
574-577: Consider tightening thefileparameter type.The
fileparameter is currently typed asany, which reduces type safety. While this may be intentional to support both Node.js file paths and browserFileobjects, consider using a more specific union type.For example, you could define:
/** * Upload a part in a multipart upload transaction. + * @param file - File path (string), Buffer, Readable stream, or File object */ - uploadPart(name: string, uploadId: string, partNo: number, file: any, start: number, end: number, options?: UploadPartOptions): Promise<UploadPartResult>; + uploadPart(name: string, uploadId: string, partNo: number, file: string | Buffer | Readable | File, start: number, end: number, options?: UploadPartOptions): Promise<UploadPartResult>;Note: This assumes
Fileis available in the target environment. If supporting both Node.js and browser, you might need to handle this with conditional types or accept theanytype with clear JSDoc documentation.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
index.test-d.ts(3 hunks)src/index.ts(2 hunks)
🧰 Additional context used
🧬 Code graph analysis (1)
index.test-d.ts (1)
src/index.ts (2)
UploadPartOptions(413-418)UploadPartResult(420-425)
🔇 Additional comments (4)
src/index.ts (1)
413-425: LGTM! Interfaces follow established patterns.The
UploadPartOptionsandUploadPartResultinterfaces are well-structured and consistent with similar interfaces in the codebase (e.g.,UploadPartCopyOptionsandUploadPartCopyResult).index.test-d.ts (3)
43-44: LGTM! Import statements are correct.The new types
UploadPartOptionsandUploadPartResultare properly imported and placed appropriately in the import list.
159-162: LGTM! Implementation stub follows the established pattern.The
uploadPartmethod implementation is consistent with other method stubs in this test file and correctly matches the interface signature.
487-544: Type tests appear syntactically sound; verify by running the full build and test pipeline.The test cases thoroughly cover:
- Basic usage with file paths
- Options including
disabledMD5,timeout,headers, andmime- Browser
Fileobjects- Different byte ranges for multipart uploads
The
uploadPartmethod acceptsfile: any, making theFileobject usage on line 516 compatible with the type signature. The extended tsconfig (via@eggjs/tsconfig) should provide necessary DOM type definitions.To verify locally, run the complete test flow:
npm run prepublishOnly && npm testThis builds type definitions and executes the type tests via tsd.
akitaSummer
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
1
|
🎉 This PR is included in version 1.5.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Add uploadPart method for uploading a part in a multipart upload transaction:
🤖 Generated with Claude Code
Summary by CodeRabbit