Skip to content

Conversation

@killagu
Copy link
Member

@killagu killagu commented Nov 17, 2025

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

Summary by CodeRabbit

  • New Features
    • Added ability to upload individual file parts as part of multipart uploads.
    • Configurable upload options: custom headers, MIME type, and optional MD5 checksum control.
    • Part upload now returns result details (including part identifier/etag and server response) for resumable or multipart workflows.

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>
@coderabbitai
Copy link

coderabbitai bot commented Nov 17, 2025

Note

Other AI code review bot(s) detected

CodeRabbit 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.

Walkthrough

Adds two public types (UploadPartOptions, UploadPartResult) and a new SimpleClient method signature uploadPart(...) for uploading an individual multipart upload part to the public API/type declarations.

Changes

Cohort / File(s) Summary
Public API types & tests
index.test-d.ts
Added UploadPartOptions and UploadPartResult to public exports and added SimpleClient.uploadPart(name, uploadId, partNo, file, start, end, options?): Promise<UploadPartResult> signature.
Core interface declarations
src/index.ts
Added UploadPartOptions (extends RequestOptions with headers, mime, disabledMD5) and UploadPartResult (name, etag, res); added IObjectSimple.uploadPart(...) method signature with JSDoc.

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
Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

  • Reviewers should verify type compatibility with existing RequestOptions and NormalSuccessResponse.
  • Confirm uploadPart parameter types (file: string | Buffer | Readable, start/end semantics) and consistency between src/index.ts and index.test-d.ts.
  • Check JSDoc correctness and exported symbol visibility.

Suggested reviewers

  • gxkl

Poem

🐇 I hop a small part down the stream,
A slice, a tag, a tiny gleam.
Start and end snug in a row,
ETag returns — and off we go! 📦✨

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title accurately describes the main change: adding type definitions for the uploadPart method, which aligns with the changes to src/index.ts and index.test-d.ts.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
✨ Finishing touches
  • 📝 Generate docstrings
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch feat/additional_apis

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 631700e and 15ff18b.

📒 Files selected for processing (1)
  • src/index.ts (2 hunks)
🔇 Additional comments (3)
src/index.ts (3)

413-418: LGTM! Well-structured options interface.

The UploadPartOptions interface is consistent with similar options interfaces in the codebase and includes appropriate fields for controlling the upload part operation.


420-425: LGTM! Result interface mirrors existing patterns.

The UploadPartResult interface is consistent with UploadPartCopyResult and follows established conventions for result types in this codebase.


574-577: Verify start/end parameters against OSS SDK documentation—REST API spec doesn't reference them.

The web search results show the OSS REST API for UploadPart expects PUT /ObjectName?partNumber=PartNumber&uploadId=UploadId with required headers including Content-Length, but no explicit start and end parameters are documented. These may be SDK-specific abstractions for partial file uploads, but this needs confirmation against the actual OSS Node.js SDK implementation or complete API documentation to rule out type correctness issues.


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.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@gemini-code-assist
Copy link

Summary of Changes

Hello @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 uploadPart method. This method facilitates the upload of individual parts within a multipart upload transaction, providing robust type safety for both the input options and the expected results. The changes ensure that developers can confidently use this functionality with clear type guidance, improving the overall reliability and maintainability of multipart upload operations.

Highlights

  • New Type Definitions for Multipart Uploads: Introduced UploadPartOptions and UploadPartResult interfaces to provide clear type definitions for configuring and handling responses from multipart upload part operations.
  • Enhanced uploadPart Method Signature: Added the uploadPart method signature to the IObjectSimple interface, supporting flexible input types including file paths and File objects, along with byte range specifications for partial uploads.
  • Comprehensive Type Tests: Implemented extensive type tests in index.test-d.ts to validate the correct usage and type inference of the new uploadPart method across various scenarios, ensuring type safety and developer confidence.
Using Gemini Code Assist

The 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 /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature Command Description
Code Review /gemini review Performs a code review for the current pull request in its current state.
Pull Request Summary /gemini summary Provides a summary of the current pull request in its current state.
Comment @gemini-code-assist Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help /gemini help Displays a list of available commands.

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 .gemini/ folder in the base of the repository. Detailed instructions can be found here.

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

  1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution.

Copy link

@gemini-code-assist gemini-code-assist bot left a 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.

Comment on lines +159 to +162
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;
}

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

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>;

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

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.

Suggested change
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>;

Copy link

@coderabbitai coderabbitai bot left a 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 the file parameter type.

The file parameter is currently typed as any, which reduces type safety. While this may be intentional to support both Node.js file paths and browser File objects, 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 File is available in the target environment. If supporting both Node.js and browser, you might need to handle this with conditional types or accept the any type with clear JSDoc documentation.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between cd9829a and 631700e.

📒 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 UploadPartOptions and UploadPartResult interfaces are well-structured and consistent with similar interfaces in the codebase (e.g., UploadPartCopyOptions and UploadPartCopyResult).

index.test-d.ts (3)

43-44: LGTM! Import statements are correct.

The new types UploadPartOptions and UploadPartResult are properly imported and placed appropriately in the import list.


159-162: LGTM! Implementation stub follows the established pattern.

The uploadPart method 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, and mime
  • Browser File objects
  • Different byte ranges for multipart uploads

The uploadPart method accepts file: any, making the File object 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 test

This builds type definitions and executes the type tests via tsd.

Copy link

@akitaSummer akitaSummer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

1

@killagu killagu enabled auto-merge (squash) November 17, 2025 11:40
@killagu killagu disabled auto-merge November 17, 2025 11:40
@killagu killagu merged commit 666d9f6 into master Nov 17, 2025
10 checks passed
@killagu killagu deleted the feat/additional_apis branch November 17, 2025 11:45
fengmk2 pushed a commit that referenced this pull request Nov 17, 2025
[skip ci]

## 1.5.0 (2025-11-17)

* feat: add uploadPart method type definition (#12) ([666d9f6](666d9f6)), closes [#12](#12)
@github-actions
Copy link

🎉 This PR is included in version 1.5.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

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

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants