Refactor data validation utilities and improve type safety

[hckhanh]

This pull request refactors the API schema typing and validation logic to improve type safety and flexibility for API requests and responses. The main changes include replacing the ApiResponse type with a more general ApiData type, updating validation utilities to support dynamic schema options, and enhancing request validation for parameterized paths.

Type system improvements

• Replaced the ApiResponse type with a new generic ApiData type, allowing extraction of any schema option ('params', 'query', 'body', 'response') for a given API path. This change provides more flexible and accurate typing for API data throughout the codebase.
• Updated all relevant type imports and exports to use ApiData instead of ApiResponse, and clarified type parameter names for better readability and maintainability. [1] [2] [3]

Validation logic improvements

• Refactored the validateData utility to use the new ApiData type and accept dynamic schema options, improving reusability and type safety for validating different parts of an API request or response.
• Added a new validateRequestData utility that validates params, query, and body for a given API path, and throws an error if a parameterized path lacks a corresponding params schema. This ensures runtime safety for parameterized API endpoints.

API fetch function changes

• Updated the createFetch function to use validateRequestData for validating request options and to return the correct ApiData type for responses. Also improved handling of request bodies to avoid sending undefined or null values. [1] [2]

[gemini-code-assist]

Summary of Changes

Hello @hckhanh, I'm Gemini Code Assist¹! 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 overhauls the API schema typing and validation infrastructure to provide a more robust, type-safe, and flexible system. The core changes revolve around introducing a more generic data type for API interactions, centralizing and strengthening request validation logic, and refining the API fetching mechanism to integrate these improvements seamlessly. The goal is to enhance developer experience, reduce common API-related errors, and ensure greater consistency in data handling.

Highlights

• Enhanced Type Safety with ApiData: The ApiResponse type has been replaced by a more flexible ApiData type. This new generic type allows for precise extraction of any schema option (e.g., 'params', 'query', 'body', 'response') for a given API path, significantly improving type safety and readability across the codebase.
• Refactored validateData Utility: The validateData utility has been updated to leverage the new ApiData type and now accepts dynamic schema options. This refactoring enhances its reusability and ensures stronger type safety when validating different parts of an API request or response.
• New validateRequestData Utility: A new utility function, validateRequestData, has been introduced. This function is responsible for validating params, query, and body for a given API path. It also includes a crucial check to ensure that parameterized paths have a corresponding params schema defined, preventing runtime errors for API endpoints.
• Improved createFetch Function: The createFetch function now integrates the new validateRequestData utility for robust request validation. Additionally, its return type has been updated to correctly reflect the ApiData type for responses, and the handling of request bodies has been refined to explicitly avoid sending undefined or null values.
• Dependency Updates: Several dependencies have been updated or added, including arktype, valibot, and zod, indicating potential shifts or enhancements in the underlying schema validation mechanisms or broader tooling.

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

[codspeed-hq]

CodSpeed Performance Report

Merging #31 will degrade performances by 13.33%

_{Comparing new-features (e1c9409) with main (7a020a1)}

Summary

❌ 2 regressions
✅ 2 untouched
⏩ 157 skipped¹

⚠️ Please fix the performance issues or acknowledge them on CodSpeed.

Benchmarks breakdown

	Benchmark	BASE	HEAD	Change
❌	GET request with shared init	122.9 µs	137.7 µs	-10.78%
❌	POST request with body	100.8 µs	116.4 µs	-13.33%

Footnotes

1. 157 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.00%. Comparing base (03dcb24) to head (e1c9409).
⚠️ Report is 3 commits behind head on main.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@            Coverage Diff            @@
##              main       #31   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files            3         3           
  Lines           48        72   +24     
  Branches        14        21    +7     
=========================================
+ Hits            48        72   +24     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[hckhanh]

@copilot I make a lot of changes to the codebase, please update documentations and tests.

[Copilot]

@hckhanh I've opened a new pull request, #32, to work on those changes. Once the pull request is ready, I'll request review from you.

[gemini-code-assist]

Code Review

This pull request is a great step forward in improving the type safety and flexibility of the API client. The introduction of the generic ApiData type and the validateRequestData utility are excellent changes.

I've identified a few areas for improvement:

• There's a critical bug in validateRequestData where a stateful regular expression is used, which can lead to incorrect runtime behavior.
• The validateRequestData function currently uses a type assertion that discards the specific types of the validated data. I've suggested a fix which involves a small change to the ApiData type to better handle optional schema parts, thereby preserving the strong types and fully achieving the goals of this refactoring.

Addressing these points will make the implementation more robust and fully leverage the power of TypeScript for a truly type-safe API client.

[Copilot]

Pull Request Overview

This PR refactors the schema validation and type system to improve flexibility and type safety. The main change replaces the specific ApiResponse type with a more general ApiData type that can extract any schema option (params, query, body, or response), and introduces a new validateRequestData utility to validate request data and enforce parameterized path requirements.

• Introduces ApiData<Schemas, Path, Option> type for flexible schema data extraction
• Adds validateRequestData utility to validate request params, query, and body together
• Enhances body handling to explicitly check for undefined and null before stringifying

Reviewed Changes

Copilot reviewed 3 out of 4 changed files in this pull request and generated 7 comments.

File	Description
src/types.ts	Replaces ApiResponse with more flexible ApiData type that accepts an Option parameter to extract any schema field; updates type parameter names for clarity
src/utils.ts	Refactors validateData to use new ApiData type and accept dynamic schema options; adds new validateRequestData function to validate all request data and check parameterized paths
src/index.ts	Updates imports/exports to use ApiData; integrates validateRequestData for request validation; improves body handling to avoid sending undefined/null
deno.lock	Adds schema library dependencies (arktype, valibot, zod) for testing; updates syncpack and other dependency versions

[hckhanh]

@copilot update tests

[Copilot]

@hckhanh I've opened a new pull request, #33, to work on those changes. Once the pull request is ready, I'll request review from you.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Copilot]

@hckhanh I've opened a new pull request, #34, to work on those changes. Once the pull request is ready, I'll request review from you.