[SDK] Feature: update hey-api version to 0.76.0 #7431
Conversation
PaoloRollo
added
merge-queue
🦋 Changeset detectedLatest commit: a036969 The changes in this PR will be included in the next version bump. This PR includes changesets to release 5 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎ 5 Skipped Deployments
|
Merge activity
|
## Walkthrough
This update replaces the dependency on `@hey-api/client-fetch` with new, locally implemented HTTP client modules in the `engine`, `insight`, and `nebula` packages. It introduces comprehensive, type-safe client libraries with utilities for serialization, authentication, interceptors, and configuration management. Type definitions for API responses and requests are updated and extended, including improved documentation, support for new fields, and more accurate typing for numeric and address fields. TypeScript configurations are updated to support iterable DOM interfaces. Minor logic adjustments ensure consistent handling of data types, such as `chainId`.
## Changes
| File(s) / Path(s) | Change Summary |
|-----------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------|
| `.changeset/little-items-allow.md` | Adds changeset documenting the hey-api update and affected packages. |
| `packages/engine/package.json`, `packages/insight/package.json`,<br>`packages/nebula/package.json` | Remove `@hey-api/client-fetch` dependency; update `@hey-api/openapi-ts` version. |
| `packages/engine/src/client/client.gen.ts`,<br>`packages/insight/src/client/client.gen.ts`,<br>`packages/nebula/src/client/client.gen.ts` | Update import sources for client creation and config from external to local modules. |
| `packages/engine/src/client/sdk.gen.ts`,<br>`packages/insight/src/client/sdk.gen.ts`,<br>`packages/nebula/src/client/sdk.gen.ts` | Update type imports from external to local, and pluralize response/error type names. |
| `packages/engine/src/client/types.gen.ts`,<br>`packages/insight/src/client/types.gen.ts`,<br>`packages/nebula/src/client/types.gen.ts` | Extend and update API type definitions: add fields, adjust numeric/address types, improve documentation. |
| `packages/engine/src/client/client/client.ts`,<br>`packages/insight/src/client/client/client.ts`,<br>`packages/nebula/src/client/client/client.ts` | New: Implement local, fully featured HTTP client with interceptors, serialization, config, and error handling. |
| `packages/engine/src/client/client/index.ts`,<br>`packages/insight/src/client/client/index.ts`,<br>`packages/nebula/src/client/client/index.ts` | New: Centralized index modules re-exporting types and utilities for client packages. |
| `packages/engine/src/client/client/types.ts`,<br>`packages/insight/src/client/client/types.ts`,<br>`packages/nebula/src/client/client/types.ts` | New: Comprehensive TypeScript types/interfaces for client config, options, and response handling. |
| `packages/engine/src/client/client/utils.ts`,<br>`packages/insight/src/client/client/utils.ts`,<br>`packages/nebula/src/client/client/utils.ts` | New: Utility modules for URL/query serialization, header merging, config, and interceptors. |
| `packages/engine/src/client/core/auth.ts`,<br>`packages/insight/src/client/core/auth.ts`,<br>`packages/nebula/src/client/core/auth.ts` | New: Auth token types and async utility for formatting/injecting authentication. |
| `packages/engine/src/client/core/bodySerializer.ts`,<br>`packages/insight/src/client/core/bodySerializer.ts`,<br>`packages/nebula/src/client/core/bodySerializer.ts` | New: Utilities for serializing request bodies (JSON, form data, URL-encoded). |
| `packages/engine/src/client/core/params.ts`,<br>`packages/insight/src/client/core/params.ts`,<br>`packages/nebula/src/client/core/params.ts` | New: Utilities for mapping input arguments to structured HTTP request parameters. |
| `packages/engine/src/client/core/pathSerializer.ts`,<br>`packages/insight/src/client/core/pathSerializer.ts`,<br>`packages/nebula/src/client/core/pathSerializer.ts` | New: Utilities for serializing path/query parameters according to OpenAPI styles. |
| `packages/engine/src/client/core/types.ts`,<br>`packages/insight/src/client/core/types.ts`,<br>`packages/nebula/src/client/core/types.ts` | New: Core client and config TypeScript interfaces for HTTP abstraction. |
| `packages/engine/src/configure.ts`,<br>`packages/insight/src/configure.ts`,<br>`packages/nebula/src/configure.ts` | Update import source for `Config` and client utilities from external to local modules. |
| `packages/engine/tsconfig.base.json`,<br>`packages/insight/tsconfig.base.json`,<br>`packages/nebula/tsconfig.base.json` | Add `"DOM.Iterable"` to TypeScript `lib` for iterable DOM types; minor comment updates. |
| `packages/nebula/openapi-ts.config.ts` | Formatting: Adjust indentation of config object. |
| `packages/thirdweb/src/transaction/transaction-store.ts` | Ensure `chainId` is always a number by converting string values. |
## Sequence Diagram(s)
### High-Level HTTP Client Request Flow
```mermaid
sequenceDiagram
participant UserApp
participant Client
participant Interceptors
participant AuthUtil
participant Fetch
participant ResponseParser
UserApp->>Client: request(options)
Client->>Client: Merge config/options
Client->>AuthUtil: setAuthParams()
AuthUtil-->>Client: (auth headers/params)
Client->>Interceptors: Apply request interceptors
Interceptors-->>Client: (modified Request)
Client->>Fetch: fetch(Request)
Fetch-->>Client: Response
Client->>Interceptors: Apply response interceptors
Interceptors-->>Client: (modified Response)
Client->>ResponseParser: Parse response (json/text/blob/etc)
ResponseParser-->>Client: Parsed data/error
Client-->>UserApp: Return data or error (per responseStyle/throwOnError)Parameter Mapping UtilitysequenceDiagram
participant SDK
participant ParamsUtil
SDK->>ParamsUtil: buildClientParams(args, fieldsConfig)
ParamsUtil->>ParamsUtil: Map args to body/headers/path/query
ParamsUtil-->>SDK: Params { body, headers, path, query }
Possibly related PRs
Suggested reviewers
|
How to use the Graphite Merge QueueAdd either label to this PR to merge it via the merge queue:
You must have a Graphite account in order to use the merge queue. Sign up using this link. An organization admin has enabled the Graphite Merge Queue in this repository. Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue. |
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 15
🔭 Outside diff range comments (3)
packages/engine/src/configure.ts (1)
22-38: Improve customstringifyfor full BigInt & replacer support
- JSON.stringify throws when the root value is a BigInt; convert it beforehand.
- Array-form replacers are silently ignored.
- Current wrapper allocates an extra closure on every call.
Suggested change:
- const res = JSON.stringify( - value, - (key, value_) => { - const value__ = typeof value_ === "bigint" ? value_.toString() : value_; - return typeof replacer === "function" ? replacer(key, value__) : value__; - }, - space, - ); + const valueToSerialize = + typeof value === "bigint" ? value.toString() : value; + const res = JSON.stringify( + valueToSerialize, + typeof replacer === "function" + ? (key, v) => replacer(key, typeof v === "bigint" ? v.toString() : v) + : (key, v) => (typeof v === "bigint" ? v.toString() : v), + space, + );This handles top-level BigInt, preserves array replacers, and avoids unnecessary allocations.
packages/nebula/src/client/core/pathSerializer.ts (1)
1-180: Consider extracting shared serialization logic to avoid duplication.This file is identical to
packages/insight/src/client/core/pathSerializer.ts. The same type safety issues exist here.Consider creating a shared internal package (e.g.,
@thirdweb-dev/client-core) to house common utilities like this path serializer. This would:
- Eliminate code duplication
- Ensure consistency across packages
- Simplify maintenance and bug fixes
- Reduce bundle size for users who import multiple packages
packages/nebula/src/client/client/types.ts (1)
1-223: Eliminate code duplication across packages.This file is an exact duplicate of
packages/engine/src/client/client/types.ts. Having identical type definitions across multiple packages violates the DRY principle and makes maintenance difficult.Consider creating a shared package or module for common client types that can be imported by engine, nebula, and insight packages. This would ensure consistency and reduce maintenance overhead.
Options:
- Create a
@thirdweb-dev/client-corepackage with shared types- Move common types to an existing shared package
- Use workspace references to share types from a single source
♻️ Duplicate comments (7)
packages/nebula/src/client/core/types.ts (1)
77-85: Same outdated documentation reference as in engine package.The same Axios reference issue exists here. Since this is duplicated code, fixing the duplication would also resolve this documentation inconsistency.
packages/nebula/src/client/core/params.ts (1)
1-141: Critical: Identical complex logic duplicated across packages.This file is identical to
packages/engine/src/client/core/params.ts. Duplicating complex parameter building logic across multiple packages creates significant maintenance overhead and increases the risk of bugs due to inconsistent updates.The same technical issues identified in the engine package apply here:
- Line 100: Non-null assertion risk
- Lines 66-72: Incomplete empty slot detection
Recommended approach:
- Extract this logic to a shared client utilities package
- Have all packages import from the shared implementation
- This ensures consistency and reduces maintenance burden
// Create packages/client-core/src/params.ts with this logic // Then import in each package: +import { buildClientParams } from "@thirdweb-dev/client-core";packages/nebula/src/client/client/client.ts (1)
1-189: Identical implementation to insight package client.This file is identical to
packages/insight/src/client/client/client.ts. While this might be intentional for package independence, consider extracting shared client logic to a common package to reduce maintenance burden and ensure consistency.The same error handling type safety issues identified in the insight package apply here (lines 142-171).
packages/engine/src/client/client/client.ts (1)
1-189: Third identical client implementation across packages.This is the third identical copy of the client implementation (also in insight and nebula packages). The duplication pattern strongly suggests extracting this to a shared internal package.
Consider creating a shared
@thirdweb-dev/internal-http-clientpackage to house this common implementation, reducing the maintenance burden of keeping three copies in sync.packages/engine/src/client/core/pathSerializer.ts (1)
1-180: Third instance of duplicated path serializer code.This file is identical to both
packages/insight/src/client/core/pathSerializer.tsandpackages/nebula/src/client/core/pathSerializer.ts.The code duplication across three packages significantly increases maintenance burden. Please consolidate these into a shared module.
packages/engine/src/client/client/utils.ts (1)
1-418: Similar utilities file with duplicated code and same issues.This file is very similar to
packages/nebula/src/client/client/utils.tswith minor differences (e.g., explicit "header" case on line 216).The same issues exist here:
- Label style encoding issue (line 86-88)
- Return type mismatch in
getParseAs(line 160)- Interceptor index bug (line 339)
Consider consolidating these utility functions into a shared package to avoid maintaining multiple versions.
packages/insight/src/client/client/types.ts (1)
1-223: Code duplication across packages.This file is another duplicate of the client types, identical to both
packages/engine/src/client/client/types.tsandpackages/nebula/src/client/client/types.ts.Please see the previous comment about eliminating code duplication and creating a shared types module.
🧹 Nitpick comments (18)
.changeset/little-items-allow.md (1)
8-8: Consider a more descriptive changelog note
“update hey-api version to 0.76.0” is accurate but omits the larger context (internal client migration, removal of@hey-api/client-fetch). A one-liner such as “Upgrade to hey-api 0.76.0 and migrate to in-house HTTP client” gives consumers better insight when scanning the changelog.packages/nebula/src/configure.ts (2)
2-6: Path looks correct but consider re-exporting to avoid “client/client”
"./client/client/index.js"is accurate relative to this file, yet it leaks the generated folder structure into public imports.
A tiny re-export stub atsrc/client/index.ts(already present in Engine/Insight) would let you import"./client/index.js"everywhere and keep future refactors internal.-} from "./client/client/index.js"; +} from "./client/index.js";You’d just need to add:
// src/client/index.ts export * from "./client/index.js";
64-80:stringifycould use stronger typingUsing
anycircumvents the benefit of strict TS. Swap tounknownand cast inside; it keeps the BigInt logic intact without disabling lint rules.-function stringify( - // biome-ignore lint/suspicious/noExplicitAny: JSON.stringify signature - value: any, +function stringify( + value: unknown, replacer?: (this: unknown, key: string, value: unknown) => unknown | null, space?: string | number, ) {packages/engine/src/client/core/auth.ts (1)
35-37: Consider Node.js compatibility for base64 encoding.The
btoa()function is not available in Node.js environments without a polyfill. For better cross-platform compatibility, consider using a more universal approach.- if (auth.scheme === "basic") { - return `Basic ${btoa(token)}`; - } + if (auth.scheme === "basic") { + return `Basic ${typeof btoa !== 'undefined' ? btoa(token) : Buffer.from(token).toString('base64')}`; + }Alternatively, consider using a dedicated base64 encoding utility that handles both browser and Node.js environments.
packages/nebula/src/client/core/auth.ts (1)
1-41: Consider consolidating duplicate authentication logic.This authentication module is identical to
packages/engine/src/client/core/auth.ts. Code duplication across packages increases maintenance burden and risk of inconsistencies.Consider one of these approaches:
- Create a shared utility package for common client functionality
- Extract authentication logic to a common internal module
- Ensure any changes to auth logic are consistently applied across all packages
The same Node.js compatibility concern with
btoa()applies here as well (see comment on engine auth module).packages/nebula/src/client/client/index.ts (1)
1-23: LGTM! Clean barrel export pattern.The centralized export approach provides a clean API surface and good separation of concerns. The use of
.jsextensions ensures proper ESM compatibility.Minor suggestion: Consider grouping exports more logically for better readability:
+// Core types and utilities export type { Auth } from "../core/auth.js"; export type { QuerySerializerOptions } from "../core/bodySerializer.js"; export { formDataBodySerializer, jsonBodySerializer, urlSearchParamsBodySerializer, } from "../core/bodySerializer.js"; export { buildClientParams } from "../core/params.js"; + +// Client types and functions export { createClient } from "./client.js"; export type { Client, ClientOptions, Config, CreateClientConfig, Options, OptionsLegacyParser, RequestOptions, RequestResult, ResponseStyle, TDataShape, } from "./types.js"; export { createConfig, mergeHeaders } from "./utils.js";packages/insight/src/client/core/types.ts (2)
49-60: Consider tightening headers type for better type safety.The headers type is very permissive, allowing any value type including arrays and unknown. This could lead to runtime errors if invalid header values are passed.
Consider constraining to valid header value types:
headers?: | RequestInit["headers"] | Record< string, - | string - | number - | boolean - | (string | number | boolean)[] - | null - | undefined - | unknown + string | string[] | undefined >;HTTP headers should typically be strings or string arrays for multi-value headers.
81-83: Update outdated documentation reference.The comment references "Axios API function" but this appears to be a custom HTTP client implementation, not Axios-based.
- * This method will have no effect if the native `paramsSerializer()` Axios - * API function is used. + * This method will have no effect if a native `paramsSerializer()` + * function is used.packages/engine/src/client/core/types.ts (1)
77-85: Update outdated documentation reference.The comment references "native
paramsSerializer()Axios API function" which is misleading since this is a custom HTTP client implementation, not Axios.* A function for serializing request query parameters. By default, arrays * will be exploded in form style, objects will be exploded in deepObject * style, and reserved characters are percent-encoded. * - * This method will have no effect if the native `paramsSerializer()` Axios - * API function is used. + * This method provides custom query parameter serialization behavior. * * {@link https://swagger.io/docs/specification/serialization/#query View examples}packages/insight/src/client/core/bodySerializer.ts (2)
17-23: Consider type safety improvement for FormData serialization.The
serializeFormDataPairfunction usesunknowntype for the value parameter, but only handles string and Blob types explicitly. Consider adding more specific type guards or error handling for unsupported types.const serializeFormDataPair = (data: FormData, key: string, value: unknown) => { if (typeof value === "string" || value instanceof Blob) { data.append(key, value); + } else if (value instanceof File) { + data.append(key, value); } else { data.append(key, JSON.stringify(value)); } };
37-84: Consider consolidating duplicate serialization logic.The FormData and URLSearchParams serializers share very similar iteration and null-checking logic. Consider extracting a common utility function to reduce code duplication.
+const processEntries = <T>( + body: Record<string, any> | Array<Record<string, any>>, + processor: (key: string, value: unknown) => void +) => { + Object.entries(body).forEach(([key, value]) => { + if (value === undefined || value === null) { + return; + } + if (Array.isArray(value)) { + value.forEach((v) => processor(key, v)); + } else { + processor(key, value); + } + }); +}; export const formDataBodySerializer = { bodySerializer: <T extends Record<string, any> | Array<Record<string, any>>>( body: T, ) => { const data = new FormData(); - Object.entries(body).forEach(([key, value]) => { - if (value === undefined || value === null) { - return; - } - if (Array.isArray(value)) { - value.forEach((v) => serializeFormDataPair(data, key, v)); - } else { - serializeFormDataPair(data, key, value); - } - }); + processEntries(body, (key, value) => serializeFormDataPair(data, key, value)); return data; }, };packages/engine/src/client/core/params.ts (1)
66-72: Consider edge case in empty slot detection.The
stripEmptySlotsfunction only removes objects with no keys, but doesn't handle other "empty" values like empty arrays or null values that might be assigned to slots.const stripEmptySlots = (params: Params) => { for (const [slot, value] of Object.entries(params)) { - if (value && typeof value === "object" && !Object.keys(value).length) { + if ( + (value && typeof value === "object" && !Array.isArray(value) && !Object.keys(value).length) || + (Array.isArray(value) && value.length === 0) || + value === null || + value === undefined + ) { delete params[slot as Slot]; } } };packages/nebula/src/client/core/bodySerializer.ts (1)
65-84: URLSearchParams serializer maintains consistency with FormData implementation.The implementation correctly mirrors the FormData serializer's logic and properly returns the string representation.
Consider extracting the common iteration logic (lines 71-80) shared with
formDataBodySerializerinto a reusable helper function to reduce code duplication:+const iterateBodyEntries = <T>( + body: T, + callback: (key: string, value: unknown) => void +) => { + Object.entries(body).forEach(([key, value]) => { + if (value === undefined || value === null) { + return; + } + if (Array.isArray(value)) { + value.forEach((v) => callback(key, v)); + } else { + callback(key, value); + } + }); +};packages/insight/src/client/core/params.ts (1)
98-105: Consider adding runtime safety for map access.The non-null assertion on line 100 assumes the key exists in the map. While
buildKeyMapshould guarantee this, consider adding a runtime check for safety:if (config.key) { - const field = map.get(config.key)!; + const field = map.get(config.key); + if (!field) { + throw new Error(`Field configuration error: key "${config.key}" not found in map`); + } const name = field.map || config.key; (params[field.in] as Record<string, unknown>)[name] = arg; }packages/nebula/src/client/client/utils.ts (1)
205-219: Add explicit "header" case for clarity.While the default case handles header authentication, being explicit improves code clarity.
switch (auth.in) { case "query": if (!options.query) { options.query = {}; } options.query[name] = token; break; case "cookie": options.headers.append("Cookie", `${name}=${token}`); break; + case "header": default: options.headers.set(name, token); break; }packages/engine/src/client/client/types.ts (1)
201-222: Add documentation for complex legacy parser type.This conditional type handles various legacy parsing scenarios but lacks documentation explaining its purpose and behavior.
Consider adding a JSDoc comment:
+/** + * Utility type for legacy parsing that conditionally includes or omits + * body and headers based on the shape of TData. This ensures backward + * compatibility with different request data formats. + */ export type OptionsLegacyParser<packages/insight/src/client/client/utils.ts (1)
295-300: Consider making header object serialization configurable.The function assumes all object headers should be JSON stringified, which might not always be appropriate for all APIs.
Consider accepting a serialization function as an optional parameter:
export const mergeHeaders = ( + options?: { objectSerializer?: (value: unknown) => string }, ...headers: Array<Required<Config>["headers"] | undefined> ): Headers => {Then use it for object serialization:
- typeof value === "object" ? JSON.stringify(value) : (value as string), + typeof value === "object" + ? (options?.objectSerializer?.(value) ?? JSON.stringify(value)) + : (value as string),packages/insight/src/client/types.gen.ts (1)
3233-3237: Clarify the input parameter documentationThe comment "hash" on line 3234 is potentially misleading since the full description indicates the input can be various types including block numbers, addresses, and signatures - not just hashes.
Consider removing the "hash" comment or expanding it to better reflect the parameter's versatility:
/** - * hash * Can be a block number, transaction or block hash, address, event signature or function selector */
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (48)
.changeset/little-items-allow.md(1 hunks)packages/engine/package.json(1 hunks)packages/engine/src/client/client.gen.ts(1 hunks)packages/engine/src/client/client/client.ts(1 hunks)packages/engine/src/client/client/index.ts(1 hunks)packages/engine/src/client/client/types.ts(1 hunks)packages/engine/src/client/client/utils.ts(1 hunks)packages/engine/src/client/core/auth.ts(1 hunks)packages/engine/src/client/core/bodySerializer.ts(1 hunks)packages/engine/src/client/core/params.ts(1 hunks)packages/engine/src/client/core/pathSerializer.ts(1 hunks)packages/engine/src/client/core/types.ts(1 hunks)packages/engine/src/client/sdk.gen.ts(14 hunks)packages/engine/src/client/types.gen.ts(5 hunks)packages/engine/src/configure.ts(1 hunks)packages/engine/tsconfig.base.json(1 hunks)packages/insight/package.json(1 hunks)packages/insight/src/client/client.gen.ts(1 hunks)packages/insight/src/client/client/client.ts(1 hunks)packages/insight/src/client/client/index.ts(1 hunks)packages/insight/src/client/client/types.ts(1 hunks)packages/insight/src/client/client/utils.ts(1 hunks)packages/insight/src/client/core/auth.ts(1 hunks)packages/insight/src/client/core/bodySerializer.ts(1 hunks)packages/insight/src/client/core/params.ts(1 hunks)packages/insight/src/client/core/pathSerializer.ts(1 hunks)packages/insight/src/client/core/types.ts(1 hunks)packages/insight/src/client/sdk.gen.ts(44 hunks)packages/insight/src/client/types.gen.ts(70 hunks)packages/insight/src/configure.ts(1 hunks)packages/insight/tsconfig.base.json(1 hunks)packages/nebula/openapi-ts.config.ts(1 hunks)packages/nebula/package.json(1 hunks)packages/nebula/src/client/client.gen.ts(1 hunks)packages/nebula/src/client/client/client.ts(1 hunks)packages/nebula/src/client/client/index.ts(1 hunks)packages/nebula/src/client/client/types.ts(1 hunks)packages/nebula/src/client/client/utils.ts(1 hunks)packages/nebula/src/client/core/auth.ts(1 hunks)packages/nebula/src/client/core/bodySerializer.ts(1 hunks)packages/nebula/src/client/core/params.ts(1 hunks)packages/nebula/src/client/core/pathSerializer.ts(1 hunks)packages/nebula/src/client/core/types.ts(1 hunks)packages/nebula/src/client/sdk.gen.ts(1 hunks)packages/nebula/src/client/types.gen.ts(3 hunks)packages/nebula/src/configure.ts(1 hunks)packages/nebula/tsconfig.base.json(1 hunks)packages/thirdweb/src/transaction/transaction-store.ts(1 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
`**/*.@(ts|tsx)`: Accept a typed 'props' object and export a named function (e.g., export function MyComponent()). Combine class names via 'cn', expose 'className' prop if useful. ...
**/*.@(ts|tsx): Accept a typed 'props' object and export a named function (e.g., export function MyComponent()).
Combine class names via 'cn', expose 'className' prop if useful.
Reuse core UI primitives; avoid re-implementing buttons, cards, modals.
Local state or effects live inside; data fetching happens in hooks.
Merge class names with 'cn' from '@/lib/utils' to keep conditional logic readable.
Stick to design-tokens: background ('bg-card'), borders ('border-border'), muted text ('text-muted-foreground') etc.
Use the 'container' class with a 'max-w-7xl' cap for page width consistency.
Spacing utilities ('px-', 'py-', 'gap-*') are preferred over custom margins.
Responsive helpers follow mobile-first ('max-sm', 'md', 'lg', 'xl').
Never hard-code colors – always go through Tailwind variables.
Tailwind CSS is the styling system – avoid inline styles or CSS modules.
Prefix files with 'import "server-only";' so they never end up in the client bundle (for server-only code).
packages/insight/src/configure.tspackages/insight/src/client/client.gen.tspackages/nebula/src/configure.tspackages/engine/src/configure.tspackages/engine/src/client/client.gen.tspackages/nebula/src/client/client.gen.tspackages/nebula/src/client/sdk.gen.tspackages/nebula/openapi-ts.config.tspackages/thirdweb/src/transaction/transaction-store.tspackages/engine/src/client/core/auth.tspackages/engine/src/client/types.gen.tspackages/nebula/src/client/client/index.tspackages/engine/src/client/client/index.tspackages/insight/src/client/sdk.gen.tspackages/engine/src/client/core/types.tspackages/insight/src/client/core/auth.tspackages/nebula/src/client/types.gen.tspackages/engine/src/client/core/params.tspackages/insight/src/client/core/types.tspackages/nebula/src/client/core/auth.tspackages/nebula/src/client/core/types.tspackages/insight/src/client/core/bodySerializer.tspackages/nebula/src/client/core/params.tspackages/insight/src/client/client/index.tspackages/engine/src/client/core/bodySerializer.tspackages/nebula/src/client/core/bodySerializer.tspackages/engine/src/client/sdk.gen.tspackages/nebula/src/client/client/utils.tspackages/engine/src/client/client/client.tspackages/insight/src/client/core/pathSerializer.tspackages/insight/src/client/client/client.tspackages/insight/src/client/core/params.tspackages/nebula/src/client/core/pathSerializer.tspackages/nebula/src/client/client/client.tspackages/engine/src/client/core/pathSerializer.tspackages/insight/src/client/client/utils.tspackages/engine/src/client/client/types.tspackages/engine/src/client/client/utils.tspackages/nebula/src/client/client/types.tspackages/insight/src/client/client/types.tspackages/insight/src/client/types.gen.ts
🧬 Code Graph Analysis (7)
packages/engine/src/client/core/types.ts (3)
packages/insight/src/client/core/types.ts (2)
Client(8-30)Config(32-98)packages/engine/src/client/core/auth.ts (2)
Auth(3-18)AuthToken(1-1)packages/engine/src/client/core/bodySerializer.ts (3)
BodySerializer(9-9)QuerySerializer(7-7)QuerySerializerOptions(11-15)
packages/nebula/src/client/core/bodySerializer.ts (3)
packages/nebula/src/client/client/index.ts (4)
QuerySerializerOptions(2-2)formDataBodySerializer(4-4)jsonBodySerializer(5-5)urlSearchParamsBodySerializer(6-6)packages/nebula/src/client/core/pathSerializer.ts (3)
SerializerOptions(10-16)ArrayStyle(18-18)ObjectStyle(21-21)packages/vault-sdk/src/transaction-types.ts (1)
Blob(135-135)
packages/nebula/src/client/client/utils.ts (6)
packages/nebula/src/client/core/pathSerializer.ts (5)
ArrayStyle(18-18)ArraySeparatorStyle(19-19)serializeArrayParam(67-109)serializeObjectParam(129-179)serializePrimitiveParam(111-127)packages/nebula/src/client/client/index.ts (7)
QuerySerializerOptions(2-2)Config(13-13)RequestOptions(17-17)Client(11-11)Options(15-15)ClientOptions(12-12)jsonBodySerializer(5-5)packages/nebula/src/client/core/bodySerializer.ts (3)
QuerySerializerOptions(11-15)QuerySerializer(7-7)jsonBodySerializer(58-63)packages/nebula/src/client/client/types.ts (5)
Config(10-59)RequestOptions(61-82)Client(165-167)Options(191-199)ClientOptions(129-133)packages/nebula/src/client/core/types.ts (2)
Config(32-98)Client(8-30)packages/nebula/src/client/core/auth.ts (1)
getAuthToken(20-40)
packages/insight/src/client/client/client.ts (3)
packages/insight/src/client/client/utils.ts (7)
mergeHeaders(275-305)mergeConfigs(266-273)createConfig(408-416)createInterceptors(386-390)setAuthParams(189-222)buildUrl(224-236)getParseAs(148-187)packages/insight/src/client/client/types.ts (3)
Config(10-59)Client(165-167)RequestOptions(61-82)packages/insight/src/client/core/types.ts (2)
Config(32-98)Client(8-30)
packages/insight/src/client/core/params.ts (1)
packages/engine/src/client/core/params.ts (4)
Field(3-13)Fields(15-18)FieldsConfig(20-20)buildClientParams(74-141)
packages/engine/src/client/core/pathSerializer.ts (1)
packages/insight/src/client/core/pathSerializer.ts (10)
SerializerOptions(10-16)ArrayStyle(18-18)ArraySeparatorStyle(19-19)ObjectStyle(21-21)separatorArrayExplode(28-39)separatorArrayNoExplode(41-52)separatorObjectExplode(54-65)serializeArrayParam(67-109)serializePrimitiveParam(111-127)serializeObjectParam(129-179)
packages/nebula/src/client/client/types.ts (3)
packages/nebula/src/client/core/types.ts (2)
Config(32-98)Client(8-30)packages/nebula/src/client/core/auth.ts (1)
Auth(3-18)packages/nebula/src/client/client/utils.ts (1)
Middleware(373-383)
⏰ Context from checks skipped due to timeout of 90000ms (3)
- GitHub Check: Size
- GitHub Check: Unit Tests
- GitHub Check: Socket Security: Pull Request Alerts
🔇 Additional comments (50)
packages/nebula/tsconfig.base.json (1)
23-25: LGTM – iterable DOM typings enabled
AddingDOM.Iterableresolves missing iterator methods (e.g.Headers.entries()); no issues spotted.packages/insight/src/configure.ts (1)
1-3: Verify post-build path resolution
The type-only import points to./client/client/index.js, which is correct for NodeNext ESM provided the compiled file ends up at the same relative path. After the build, confirm that
dist/client/client/index.js(or your outDir equivalent) exists to avoid runtime resolution errors.#!/bin/bash # Ensure the built file exists (adjust OUT_DIR if different) OUT_DIR=packages/insight/dist test -f "$OUT_DIR/client/client/index.js" && echo "✓ path ok" || { echo "✗ missing"; exit 1; }packages/engine/src/configure.ts (1)
1-3: Same path concern as in Insight
Double-check that./client/client/index.jsexists in the emitted output; otherwise consumers will hit a module-not-found at runtime.packages/nebula/src/client/sdk.gen.ts (1)
3-8: Generated file – path update looks correct
Import now targets the new local client. No issues noted; leaving as generated.packages/insight/package.json (1)
30-35: Ensure the external@hey-api/client-fetchcode path is truly goneBumping
@hey-api/openapi-tsis fine, but removal of@hey-api/client-fetchonly pays off if no residual import remains in the Insight package (including tests and generated code).#!/bin/bash # List all occurrences of the old client inside the insight package rg --line-number --pretty '@hey-api/client-fetch' packages/insight || truepackages/engine/src/client/client.gen.ts (1)
3-9: Import path swap LGTMGenerated code now consumes the in-house client (
./client/index.js). No issues spotted.packages/insight/src/client/client.gen.ts (1)
3-9: Consistent with Engine ‑ goodThe generator was updated to the new local client path and compiles cleanly.
packages/engine/package.json (1)
30-35: Mirror the verification done for InsightSame comment as for Insight: double-check that no code in
enginestill references@hey-api/client-fetch.#!/bin/bash rg --line-number --pretty '@hey-api/client-fetch' packages/engine || truepackages/nebula/src/client/client.gen.ts (1)
8-8: Import path looks correct – just verify build output location
"./client/index.js"resolves tosrc/client/client/index.ts→dist/.../client/index.js, which matches the new folder layout.
No issues spotted here.packages/insight/tsconfig.base.json (1)
22-25: Good addition ofDOM.IterableThis unblocks typing for
Headers.entries()and similar APIs required by the new HTTP client. 👍packages/engine/tsconfig.base.json (1)
22-25: Consistent lib targetsAdding
"DOM.Iterable"keepsenginein sync with the other packages and prevents type mismatches. Looks good.packages/thirdweb/src/transaction/transaction-store.ts (1)
88-89: LGTM! Good defensive programming.The type conversion ensures chainId is consistently a number, handling cases where the API might return it as a string. This enhances type safety and prevents potential runtime issues.
packages/nebula/src/client/types.gen.ts (3)
547-550: LGTM! Consistent API evolution.The addition of the optional
summaryfield follows proper TypeScript conventions and maintains backward compatibility.
278-281: LGTM! Consistent field addition.The
summaryfield is consistently added across related response types, maintaining API coherence.
4277-4277: Verify the production baseUrl is correct.The baseUrl has been updated from localhost to production. Ensure this URL is correct and accessible.
#!/bin/bash # Description: Verify the production API endpoint is accessible # Expected: HTTP response indicating the API is reachable curl -I "https://nebula-api.thirdweb-dev.com" --connect-timeout 10 --max-time 30packages/insight/src/client/sdk.gen.ts (2)
7-7: LGTM! Client migration to internal implementation.The import path change from external
@hey-api/client-fetchto internal./client/index.jsaligns with the PR's goal of reducing external dependencies.
11-133: Verify type name consistency across the codebase.The type names have been systematically changed from singular to plural forms (e.g.,
GetV1WebhooksResponse→GetV1WebhooksResponses). This could be a breaking change for external consumers.#!/bin/bash # Description: Check for any remaining references to the old singular type names # Expected: No results if migration is complete echo "Checking for old singular type names..." rg -i "GetV1WebhooksResponse[^s]|GetV1BlocksResponse[^s]|GetV1EventsResponse[^s]" --type ts --type jspackages/engine/src/client/types.gen.ts (2)
20-23: LGTM! Improved documentation clarity.The descriptive JSDoc comments clearly explain the purpose of each execution option type, making the API more self-documenting and developer-friendly.
Also applies to: 43-45, 79-82
139-139: LGTM! Enhanced account labeling support.The optional
labelproperty addition provides better UX by allowing human-readable identifiers alongside addresses, which is valuable for account management interfaces.Also applies to: 176-176
packages/engine/src/client/core/auth.ts (1)
20-40: LGTM! Well-designed authentication token handler.The function elegantly handles both callback and direct token patterns with proper type safety. The scheme-based formatting (bearer/basic) follows standard HTTP authentication practices.
packages/insight/src/client/core/types.ts (1)
8-30: LGTM! Well-designed client interfaces.The generic Client interface provides comprehensive HTTP method coverage with flexible type parameters. The Config interface is well-documented and supports both synchronous and asynchronous authentication patterns.
Also applies to: 32-98
packages/engine/src/client/client/index.ts (1)
1-22: Well-structured barrel export module.The export organization is clean and follows good practices with proper separation of types vs. values and logical grouping of related functionality. The consistent use of
.jsextensions supports ESM compatibility.packages/insight/src/client/core/auth.ts (1)
1-40: Solid authentication implementation.The auth types and token handling function are well-designed. The
getAuthTokenfunction correctly handles both synchronous and asynchronous token resolution, and the authentication schemes (bearer/basic) are implemented according to standards.packages/engine/src/client/core/types.ts (2)
8-30: Well-designed Client interface with proper generics.The Client interface is well-structured with appropriate generic parameters that provide flexibility for different implementations while maintaining type safety.
32-98: Comprehensive Config interface with good type safety.The Config interface covers all necessary HTTP client configuration options with appropriate type definitions and helpful documentation.
packages/insight/src/client/client/index.ts (1)
1-22: Consistent barrel export structure across packages.The export organization matches the engine package structure, maintaining consistency in the modular design. This promotes predictable imports and good developer experience across the codebase.
packages/engine/src/client/sdk.gen.ts (3)
7-7: LGTM: Clean transition to internal client implementation.The import path update from the external
@hey-api/client-fetchpackage to the local./client/index.jsmodule is consistent with the PR's objective to internalize the HTTP client implementation.
15-16: LGTM: Enhanced error handling with specific error types.The addition of specific error types (
GetNativeBalanceErrors,GetTransactionAnalyticsSummaryErrors) for certain endpoints improves type safety and error handling capabilities.Also applies to: 20-21, 277-278, 387-388
11-37: Verify the pluralized type naming convention is intentional.The type names have been updated from singular to plural forms (e.g.,
CreateAccountResponse→CreateAccountResponses). While this appears consistent across all imports, please confirm this naming change aligns with the new type definitions.#!/bin/bash # Description: Verify the pluralized response type naming convention in types.gen.ts # Expected: All response types should follow the plural naming pattern rg -A 2 "export.*Response(s|Error).*=" packages/engine/src/client/types.gen.tspackages/insight/src/client/core/bodySerializer.ts (1)
58-63: LGTM: Proper bigint handling in JSON serialization.The JSON serializer correctly handles
bigintvalues by converting them to strings, which is necessary since JSON doesn't natively support bigint values.packages/engine/src/client/core/params.ts (1)
22-28: LGTM: Clean special prefix handling for flexible parameter assignment.The
extraPrefixesMapprovides a nice way to handle special prefixed keys that need to be assigned to specific slots, enhancing the flexibility of the parameter building system.packages/nebula/src/client/core/bodySerializer.ts (4)
1-15: Well-structured type definitions and imports.The type definitions for serializers are clean and the QuerySerializerOptions interface properly leverages the imported types from pathSerializer.
17-35: Helper functions properly handle type-specific serialization.The separation between FormData and URLSearchParams serialization is well-designed, with appropriate handling of native vs. complex types.
37-56: FormData serializer correctly handles arrays and null values.The implementation properly skips null/undefined values and supports multiple values per key through array handling, which aligns with standard form data behavior.
58-63: JSON serializer handles BigInt correctly.Good implementation with proper BigInt handling through string conversion.
packages/insight/src/client/client/client.ts (4)
17-25: Config management properly encapsulates state.The implementation correctly uses shallow copying to prevent external mutations and maintains clean config merging behavior.
42-56: Proper handling of authentication and empty request bodies.The code correctly handles conditional authentication, body serialization, and prevents invalid requests by removing Content-Type headers for empty bodies.
64-81: Interceptor implementation and fetch handling are well-designed.The sequential interceptor execution and the fetch assignment pattern (with explanatory comment) properly prevent the 'Illegal invocation' error. The non-null assertion is safe due to the fallback chain in line 38.
88-122: Comprehensive response parsing with proper empty response handling.The implementation correctly handles all standard response types and appropriately manages empty responses and streams.
packages/insight/src/client/core/params.ts (2)
1-28: Well-designed type system for parameter configuration.The discriminated union for Field types and the extra prefix mechanism provide good flexibility for parameter mapping.
38-57: Recursive key mapping is well-implemented.The function correctly handles nested field configurations and properly guards against missing keys.
packages/engine/src/client/client/types.ts (2)
10-59: Well-structured configuration interface with good type safety.The use of
next?: neverto explicitly disallow Next.js options in the Fetch client is a clever pattern for preventing configuration mistakes.
84-127: I’d like to verify howResponseStyleandRequestResultare defined and used to understand if the value‐extraction is intentional.#!/bin/bash # Show the definition of ResponseStyle rg "export type ResponseStyle" -n packages/engine/src # Locate where ResponseStyle is documented or commented rg "ResponseStyle" -C2 -n packages/engine/src # Find all usages of RequestResult to see expected shapes rg "RequestResult<" -C2 -n packages/engine/srcpackages/insight/src/client/client/utils.ts (1)
189-222: Verify early return behavior in auth processing.The function returns after processing the first valid auth token (line 220), ignoring any subsequent tokens in the security array. This behavior should be documented if intentional.
If this is the intended behavior, add a comment explaining why only the first valid token is used:
+ // Only the first valid auth token is used; subsequent tokens are ignored return;If multiple auth tokens should be processed, remove the early return.
packages/insight/src/client/types.gen.ts (6)
1-1: Caution: Manual modifications to auto-generated fileThis file is auto-generated by
@hey-api/openapi-ts. Any manual changes will be overwritten on the next generation. Ensure all type modifications are made in the source OpenAPI specification.
1221-1231: Transaction value fields changed to string typeThe change from
numbertostringfor transaction-related numeric fields (value, gas_price, etc.) is appropriate for handling large blockchain values that exceed JavaScript's safe integer range. This prevents precision loss.Also applies to: 1237-1239, 1485-1495, 1501-1503, 1739-1749, 1755-1757
1233-1233: New optional field for transaction authorizationThe addition of
authorization_list_json?: stringfield appears to support transaction authorization features. This is a non-breaking change as the field is optional.Also applies to: 1497-1497, 1751-1751, 3325-3325, 5446-5446
504-507: Improved documentation for address fieldsThe addition of JSDoc comments clarifying that address fields accept "address (hex or ENS)" improves API usability by making it clear that both formats are supported.
Also applies to: 580-583, 794-797, 1106-1107, 1175-1176, 1269-1272, 1375-1376, 1526-1529, 1633-1634
1921-1951: Enhanced token responses with comprehensive pricing dataThe addition of the
price_dataobject provides valuable market information including price, volume, market cap, and supply metrics. This enhancement improves the API's utility for token-related queries.Also applies to: 2011-2041, 2142-2171, 2232-2261, 2394-2423, 2484-2513, 2702-2731, 3193-3222
2336-2359: Enhanced filtering capabilities for transfersThe addition of timestamp ranges, owner/contract filters, sorting options, and transfer type filters significantly improves the API's querying capabilities for both token and NFT transfers.
Also applies to: 4197-4227
| "devDependencies": { | ||
| "@biomejs/biome": "2.0.4", | ||
| "@hey-api/openapi-ts": "0.72.1", | ||
| "@hey-api/openapi-ts": "0.76.0", | ||
| "rimraf": "6.0.1", | ||
| "tslib": "^2.8.1" |
There was a problem hiding this comment.
Generation plugin removed from devDependencies
openapi-ts.config.ts still references the @hey-api/client-fetch plugin, yet the package has been removed from devDependencies.
The code-gen step (pnpm build:generate) will now fail with Cannot find module '@hey-api/client-fetch'.
Either:
- add it back under
devDependencies, or - delete it from the
pluginsarray if it is no longer required.
🤖 Prompt for AI Agents
In packages/nebula/package.json around lines 34 to 38, the package
@hey-api/client-fetch was removed from devDependencies but is still referenced
in openapi-ts.config.ts plugins array. To fix this, either add
@hey-api/client-fetch back to devDependencies or remove it from the plugins
array in openapi-ts.config.ts if it is no longer needed, ensuring the code-gen
step does not fail due to missing module.
| input: "https://nebula-api.thirdweb-dev.com/openapi.json", | ||
| output: { format: "biome", lint: "biome", path: "src/client" }, | ||
| plugins: ["@hey-api/client-fetch"], | ||
| }); |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Stale plugin reference
The plugins array still declares "@hey-api/client-fetch", contradicting the new in-house client strategy and the removed dependency.
Leaving it here causes runtime require() errors during code generation.
Action: remove the plugin or point to the new local client generator if one exists.
- plugins: ["@hey-api/client-fetch"],
+ // plugins: ["@hey-api/client-fetch"], // ← delete or replace📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| input: "https://nebula-api.thirdweb-dev.com/openapi.json", | |
| output: { format: "biome", lint: "biome", path: "src/client" }, | |
| plugins: ["@hey-api/client-fetch"], | |
| }); | |
| input: "https://nebula-api.thirdweb-dev.com/openapi.json", | |
| output: { format: "biome", lint: "biome", path: "src/client" }, | |
| - plugins: ["@hey-api/client-fetch"], | |
| + // plugins: ["@hey-api/client-fetch"], // ← delete or replace | |
| }); |
🤖 Prompt for AI Agents
In packages/nebula/openapi-ts.config.ts around lines 4 to 7, the plugins array
includes the outdated "@hey-api/client-fetch" plugin, which conflicts with the
new in-house client strategy and causes runtime require() errors. Remove the
"@hey-api/client-fetch" entry from the plugins array or replace it with the
correct new local client generator plugin if available to resolve these errors.
| @@ -240,7 +248,7 @@ export const patchV1WebhooksByWebhookId = < | |||
| ...options, | |||
| headers: { | |||
| "Content-Type": "application/json", | |||
| ...options?.headers, | |||
| ...options.headers, | |||
There was a problem hiding this comment.
Fix potential runtime error from removing optional chaining.
The optional chaining has been removed from options?.headers → options.headers. This could cause runtime errors if options is undefined or doesn't have a headers property.
Apply this diff to restore safe property access:
- ...options.headers,
+ ...options?.headers,- ...options.headers,
+ ...options?.headers,Also applies to: 821-821
🤖 Prompt for AI Agents
In packages/insight/src/client/sdk.gen.ts at lines 251 and 821, the optional
chaining was removed from accessing options.headers, which can cause runtime
errors if options is undefined. To fix this, restore the optional chaining by
changing options.headers back to options?.headers to safely access headers only
when options is defined.
| import type { Auth, AuthToken } from "./auth.js"; | ||
| import type { | ||
| BodySerializer, | ||
| QuerySerializer, | ||
| QuerySerializerOptions, | ||
| } from "./bodySerializer.js"; | ||
|
|
||
| export interface Client< | ||
| RequestFn = never, | ||
| Config = unknown, | ||
| MethodFn = never, | ||
| BuildUrlFn = never, | ||
| > { | ||
| /** | ||
| * Returns the final request URL. | ||
| */ | ||
| buildUrl: BuildUrlFn; | ||
| connect: MethodFn; | ||
| delete: MethodFn; | ||
| get: MethodFn; | ||
| getConfig: () => Config; | ||
| head: MethodFn; | ||
| options: MethodFn; | ||
| patch: MethodFn; | ||
| post: MethodFn; | ||
| put: MethodFn; | ||
| request: RequestFn; | ||
| setConfig: (config: Config) => Config; | ||
| trace: MethodFn; | ||
| } | ||
|
|
||
| export interface Config { | ||
| /** | ||
| * Auth token or a function returning auth token. The resolved value will be | ||
| * added to the request payload as defined by its `security` array. | ||
| */ | ||
| auth?: ((auth: Auth) => Promise<AuthToken> | AuthToken) | AuthToken; | ||
| /** | ||
| * A function for serializing request body parameter. By default, | ||
| * {@link JSON.stringify()} will be used. | ||
| */ | ||
| bodySerializer?: BodySerializer | null; | ||
| /** | ||
| * An object containing any HTTP headers that you want to pre-populate your | ||
| * `Headers` object with. | ||
| * | ||
| * {@link https://developer.mozilla.org/docs/Web/API/Headers/Headers#init See more} | ||
| */ | ||
| headers?: | ||
| | RequestInit["headers"] | ||
| | Record< | ||
| string, | ||
| | string | ||
| | number | ||
| | boolean | ||
| | (string | number | boolean)[] | ||
| | null | ||
| | undefined | ||
| | unknown | ||
| >; | ||
| /** | ||
| * The request method. | ||
| * | ||
| * {@link https://developer.mozilla.org/docs/Web/API/fetch#method See more} | ||
| */ | ||
| method?: | ||
| | "CONNECT" | ||
| | "DELETE" | ||
| | "GET" | ||
| | "HEAD" | ||
| | "OPTIONS" | ||
| | "PATCH" | ||
| | "POST" | ||
| | "PUT" | ||
| | "TRACE"; | ||
| /** | ||
| * A function for serializing request query parameters. By default, arrays | ||
| * will be exploded in form style, objects will be exploded in deepObject | ||
| * style, and reserved characters are percent-encoded. | ||
| * | ||
| * This method will have no effect if the native `paramsSerializer()` Axios | ||
| * API function is used. | ||
| * | ||
| * {@link https://swagger.io/docs/specification/serialization/#query View examples} | ||
| */ | ||
| querySerializer?: QuerySerializer | QuerySerializerOptions; | ||
| /** | ||
| * A function transforming response data before it's returned. This is useful | ||
| * for post-processing data, e.g. converting ISO strings into Date objects. | ||
| */ | ||
| responseTransformer?: (data: unknown) => Promise<unknown>; | ||
| /** | ||
| * A function validating response data. This is useful if you want to ensure | ||
| * the response conforms to the desired shape, so it can be safely passed to | ||
| * the transformers and returned to the user. | ||
| */ | ||
| responseValidator?: (data: unknown) => Promise<unknown>; | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Address code duplication across packages.
This file is identical to packages/engine/src/client/core/types.ts. Consider consolidating these shared type definitions to reduce maintenance burden and prevent inconsistencies.
Options to address this:
- Create a shared types package that both engine and nebula can import from
- Move common types to a shared location and re-export them
- Use a code generation approach from a single source
This would improve maintainability and ensure consistency across packages.
🤖 Prompt for AI Agents
In packages/nebula/src/client/core/types.ts lines 1 to 98, the type definitions
are duplicated in packages/engine/src/client/core/types.ts. To fix this,
refactor by extracting these shared type definitions into a common shared
package or module that both nebula and engine can import from. Alternatively,
move the common types to a shared location and re-export them in each package.
This consolidation will reduce duplication and improve maintainability.
| const replaceValue = encodeURIComponent( | ||
| style === "label" ? `.${value as string}` : (value as string), | ||
| ); |
There was a problem hiding this comment.
Fix label style encoding to exclude the prefix from URL encoding.
The dot prefix for label style should not be URL-encoded.
Apply this fix:
const replaceValue = encodeURIComponent(
- style === "label" ? `.${value as string}` : (value as string),
+ value as string
);
- url = url.replace(match, replaceValue);
+ url = url.replace(match, style === "label" ? `.${replaceValue}` : replaceValue);📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| const replaceValue = encodeURIComponent( | |
| style === "label" ? `.${value as string}` : (value as string), | |
| ); | |
| const replaceValue = encodeURIComponent( | |
| value as string | |
| ); | |
| url = url.replace(match, style === "label" ? `.${replaceValue}` : replaceValue); |
🤖 Prompt for AI Agents
In packages/nebula/src/client/client/utils.ts around lines 86 to 88, the dot
prefix for the "label" style is currently included inside the encodeURIComponent
call, causing it to be URL-encoded. To fix this, move the dot prefix outside of
the encodeURIComponent function so that only the value is encoded, and then
concatenate the dot prefix before the encoded value.
| if (typeof id === "number") { | ||
| return this._fns[id] ? id : -1; | ||
| } else { | ||
| return this._fns.indexOf(id); | ||
| } | ||
| } | ||
| exists(id: number | Interceptor) { |
There was a problem hiding this comment.
Fix potential bug with interceptor index 0.
The check this._fns[id] will fail when id is 0 and could return incorrect results.
getInterceptorIndex(id: number | Interceptor): number {
if (typeof id === "number") {
- return this._fns[id] ? id : -1;
+ return id >= 0 && id < this._fns.length ? id : -1;
} else {
return this._fns.indexOf(id);
}
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| if (typeof id === "number") { | |
| return this._fns[id] ? id : -1; | |
| } else { | |
| return this._fns.indexOf(id); | |
| } | |
| } | |
| exists(id: number | Interceptor) { | |
| getInterceptorIndex(id: number | Interceptor): number { | |
| if (typeof id === "number") { | |
| - return this._fns[id] ? id : -1; | |
| + return id >= 0 && id < this._fns.length ? id : -1; | |
| } else { | |
| return this._fns.indexOf(id); | |
| } | |
| } |
🤖 Prompt for AI Agents
In packages/nebula/src/client/client/utils.ts around lines 337 to 343, the
condition this._fns[id] incorrectly treats index 0 as falsy, causing wrong
results. Replace the check with a condition that explicitly verifies if
this._fns[id] is not undefined, such as using this._fns[id] !== undefined, to
correctly handle index 0 and avoid returning -1 incorrectly.
| export const getParseAs = ( | ||
| contentType: string | null, | ||
| ): Exclude<Config["parseAs"], "auto"> => { | ||
| if (!contentType) { | ||
| // If no Content-Type header is provided, the best we can do is return the raw response body, | ||
| // which is effectively the same as the 'stream' option. | ||
| return "stream"; | ||
| } | ||
|
|
||
| const cleanContent = contentType.split(";")[0]?.trim(); | ||
|
|
||
| if (!cleanContent) { | ||
| return; | ||
| } | ||
|
|
||
| if ( | ||
| cleanContent.startsWith("application/json") || | ||
| cleanContent.endsWith("+json") | ||
| ) { | ||
| return "json"; | ||
| } | ||
|
|
||
| if (cleanContent === "multipart/form-data") { | ||
| return "formData"; | ||
| } | ||
|
|
||
| if ( | ||
| ["application/", "audio/", "image/", "video/"].some((type) => | ||
| cleanContent.startsWith(type), | ||
| ) | ||
| ) { | ||
| return "blob"; | ||
| } | ||
|
|
||
| if (cleanContent.startsWith("text/")) { | ||
| return "text"; | ||
| } | ||
|
|
||
| return; | ||
| }; |
There was a problem hiding this comment.
Fix return type inconsistency in getParseAs function.
The function returns undefined on line 160 and 186, but the return type doesn't include it.
Either update the return type or provide a default return value:
export const getParseAs = (
contentType: string | null,
-): Exclude<Config["parseAs"], "auto"> => {
+): Exclude<Config["parseAs"], "auto"> | undefined => {Or return a default value like "stream" in all cases where you currently return undefined.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| export const getParseAs = ( | |
| contentType: string | null, | |
| ): Exclude<Config["parseAs"], "auto"> => { | |
| if (!contentType) { | |
| // If no Content-Type header is provided, the best we can do is return the raw response body, | |
| // which is effectively the same as the 'stream' option. | |
| return "stream"; | |
| } | |
| const cleanContent = contentType.split(";")[0]?.trim(); | |
| if (!cleanContent) { | |
| return; | |
| } | |
| if ( | |
| cleanContent.startsWith("application/json") || | |
| cleanContent.endsWith("+json") | |
| ) { | |
| return "json"; | |
| } | |
| if (cleanContent === "multipart/form-data") { | |
| return "formData"; | |
| } | |
| if ( | |
| ["application/", "audio/", "image/", "video/"].some((type) => | |
| cleanContent.startsWith(type), | |
| ) | |
| ) { | |
| return "blob"; | |
| } | |
| if (cleanContent.startsWith("text/")) { | |
| return "text"; | |
| } | |
| return; | |
| }; | |
| export const getParseAs = ( | |
| contentType: string | null, | |
| ): Exclude<Config["parseAs"], "auto"> | undefined => { | |
| if (!contentType) { | |
| // If no Content-Type header is provided, the best we can do is return the raw response body, | |
| // which is effectively the same as the 'stream' option. | |
| return "stream"; | |
| } | |
| const cleanContent = contentType.split(";")[0]?.trim(); | |
| if (!cleanContent) { | |
| return; | |
| } | |
| if ( | |
| cleanContent.startsWith("application/json") || | |
| cleanContent.endsWith("+json") | |
| ) { | |
| return "json"; | |
| } | |
| if (cleanContent === "multipart/form-data") { | |
| return "formData"; | |
| } | |
| if ( | |
| ["application/", "audio/", "image/", "video/"].some((type) => | |
| cleanContent.startsWith(type), | |
| ) | |
| ) { | |
| return "blob"; | |
| } | |
| if (cleanContent.startsWith("text/")) { | |
| return "text"; | |
| } | |
| return; | |
| }; |
🤖 Prompt for AI Agents
In packages/nebula/src/client/client/utils.ts between lines 148 and 187, the
getParseAs function sometimes returns undefined, but its return type excludes
undefined. To fix this, ensure the function always returns a valid value of the
declared return type by replacing any return statements that currently return
undefined with a default value like "stream". This guarantees consistency with
the declared return type and avoids returning undefined.
| /** | ||
| * Infers parseAs value from provided Content-Type header. | ||
| */ | ||
| export const getParseAs = ( | ||
| contentType: string | null, | ||
| ): Exclude<Config["parseAs"], "auto"> => { | ||
| if (!contentType) { | ||
| // If no Content-Type header is provided, the best we can do is return the raw response body, | ||
| // which is effectively the same as the 'stream' option. | ||
| return "stream"; | ||
| } | ||
|
|
||
| const cleanContent = contentType.split(";")[0]?.trim(); | ||
|
|
||
| if (!cleanContent) { | ||
| return; | ||
| } | ||
|
|
||
| if ( | ||
| cleanContent.startsWith("application/json") || | ||
| cleanContent.endsWith("+json") | ||
| ) { | ||
| return "json"; | ||
| } | ||
|
|
||
| if (cleanContent === "multipart/form-data") { | ||
| return "formData"; | ||
| } | ||
|
|
||
| if ( | ||
| ["application/", "audio/", "image/", "video/"].some((type) => | ||
| cleanContent.startsWith(type), | ||
| ) | ||
| ) { | ||
| return "blob"; | ||
| } | ||
|
|
||
| if (cleanContent.startsWith("text/")) { | ||
| return "text"; | ||
| } | ||
|
|
||
| return; | ||
| }; |
There was a problem hiding this comment.
Fix return type to include undefined.
The function can return undefined at lines 160 and 186, but the return type Exclude<Config["parseAs"], "auto"> doesn't include undefined. This will cause type errors with strict null checks.
Update the return type:
export const getParseAs = (
contentType: string | null,
-): Exclude<Config["parseAs"], "auto"> => {
+): Exclude<Config["parseAs"], "auto"> | undefined => {📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| /** | |
| * Infers parseAs value from provided Content-Type header. | |
| */ | |
| export const getParseAs = ( | |
| contentType: string | null, | |
| ): Exclude<Config["parseAs"], "auto"> => { | |
| if (!contentType) { | |
| // If no Content-Type header is provided, the best we can do is return the raw response body, | |
| // which is effectively the same as the 'stream' option. | |
| return "stream"; | |
| } | |
| const cleanContent = contentType.split(";")[0]?.trim(); | |
| if (!cleanContent) { | |
| return; | |
| } | |
| if ( | |
| cleanContent.startsWith("application/json") || | |
| cleanContent.endsWith("+json") | |
| ) { | |
| return "json"; | |
| } | |
| if (cleanContent === "multipart/form-data") { | |
| return "formData"; | |
| } | |
| if ( | |
| ["application/", "audio/", "image/", "video/"].some((type) => | |
| cleanContent.startsWith(type), | |
| ) | |
| ) { | |
| return "blob"; | |
| } | |
| if (cleanContent.startsWith("text/")) { | |
| return "text"; | |
| } | |
| return; | |
| }; | |
| /** | |
| * Infers parseAs value from provided Content-Type header. | |
| */ | |
| export const getParseAs = ( | |
| contentType: string | null, | |
| ): Exclude<Config["parseAs"], "auto"> | undefined => { | |
| if (!contentType) { | |
| // If no Content-Type header is provided, the best we can do is return the raw response body, | |
| // which is effectively the same as the 'stream' option. | |
| return "stream"; | |
| } | |
| const cleanContent = contentType.split(";")[0]?.trim(); | |
| if (!cleanContent) { | |
| return; | |
| } | |
| if ( | |
| cleanContent.startsWith("application/json") || | |
| cleanContent.endsWith("+json") | |
| ) { | |
| return "json"; | |
| } | |
| if (cleanContent === "multipart/form-data") { | |
| return "formData"; | |
| } | |
| if ( | |
| ["application/", "audio/", "image/", "video/"].some((type) => | |
| cleanContent.startsWith(type), | |
| ) | |
| ) { | |
| return "blob"; | |
| } | |
| if (cleanContent.startsWith("text/")) { | |
| return "text"; | |
| } | |
| return; | |
| }; |
🤖 Prompt for AI Agents
In packages/insight/src/client/client/utils.ts around lines 145 to 187, the
function getParseAs can return undefined at lines 160 and 186, but the declared
return type Exclude<Config["parseAs"], "auto"> does not include undefined,
causing type errors. Update the return type to explicitly include undefined by
changing it to Exclude<Config["parseAs"], "auto"> | undefined to match all
possible return values.
| @@ -536,10 +537,10 @@ export type GetV1EventsResponses = { | |||
| */ | |||
| 200: { | |||
| data?: Array<{ | |||
| chain_id: number; | |||
| block_number: string; | |||
| chain_id: string; | |||
There was a problem hiding this comment.
Type inconsistency for chain_id field
The chain_id field is typed as string in response data objects but as number in meta objects and query parameters. This inconsistency will cause TypeScript errors when working with chain IDs across different parts of the API.
For example:
- Response:
chain_id: string(lines 540, 754, 965, 1212) - Meta:
chain_ids: Array<number>(lines 563, 777, 988, 1252) - Query:
chain_id?: Array<number>(lines 378, 596, 811)
Also applies to: 563-563, 754-754, 777-777, 965-965, 988-988, 1212-1212, 1252-1252
🤖 Prompt for AI Agents
In packages/insight/src/client/types.gen.ts around lines 378, 540, 563, 596,
754, 777, 811, 965, 988, 1212, and 1252, the `chain_id` field is inconsistently
typed as string in response objects but as number or array of numbers in meta
and query objects. To fix this, unify the type of `chain_id` across all these
locations by changing all instances to use the same type, preferably `number` or
`Array<number>` as appropriate, ensuring consistency and preventing TypeScript
errors.
There was a problem hiding this comment.
Actionable comments posted: 11
🔭 Outside diff range comments (3)
packages/engine/src/client/core/params.ts (1)
1-142: Address code duplication across packages.This file is identical to
packages/nebula/src/client/core/params.ts. Consider extracting shared logic to a common utility package to avoid maintenance overhead.The same issues from the nebula version apply here:
- Line 100: Non-null assertion risk
- Lines 87-96: Config variable persistence across iterations
- Lines 66-72: Mutation behavior should be documented
packages/engine/src/client/core/bodySerializer.ts (1)
1-85: Consolidate identical implementations across packages.This is the third identical copy of the bodySerializer implementation (also in
insightandnebulapackages). While the code quality is excellent, maintaining identical copies across multiple packages creates maintenance overhead.Consider:
- Creating a shared utilities package for common serialization logic
- Or documenting why separate copies are necessary (e.g., packaging constraints)
The implementation itself is robust with proper type safety and edge case handling.
packages/insight/src/client/client/utils.ts (1)
1-417: Extract duplicated utility functions to a shared module.This entire file is duplicated across the
engine,insight, andnebulapackages. This violates the DRY principle and will make maintenance difficult.Consider creating a shared package (e.g.,
@thirdweb-dev/client-utils) to house these common utilities.
♻️ Duplicate comments (11)
packages/insight/src/client/client.gen.ts (1)
8-8: Same note as Engine: verify file exists & consider centralising clientSee previous comments; duplication applies here as well.
packages/nebula/src/client/core/types.ts (1)
81-82: Fix documentation reference inconsistency.The comment mentions "native
paramsSerializer()Axios API function" but this is a fetch-based HTTP client, not Axios-based. This could confuse developers.packages/nebula/src/client/client/client.ts (2)
158-158: Fix type casting issue with error fallback.Same issue as in the engine package - incorrect type casting of empty object as string.
Apply this diff to fix:
- finalError = finalError || ({} as string); + finalError = finalError || "";
1-189: Duplicate implementation detected.This entire file is identical to
packages/engine/src/client/client/client.ts. Consider extracting to a shared module.packages/engine/src/client/core/pathSerializer.ts (1)
1-179: Duplicate implementation of pathSerializer.This file is identical to
packages/insight/src/client/core/pathSerializer.ts. Consider extracting to a shared module to maintain DRY principles.packages/nebula/src/client/core/pathSerializer.ts (1)
1-179: Duplicate implementation of pathSerializer.This file is identical to the pathSerializer in both insight and engine packages. Strong recommendation to extract to a shared module.
packages/insight/src/client/client/utils.ts (2)
148-162: Fix inconsistent return type ingetParseAsfunction.Same issue as in the engine package - the function can return
undefinedbut the return type excludes it.
175-187: Fix missing return value at the end ofgetParseAsfunction.Same issue as in the engine package - the function returns
undefinedwhich doesn't match the declared return type.packages/nebula/src/client/client/utils.ts (2)
1-417: Another instance of duplicated utility functions.This file is identical to the utils files in both
engineandinsightpackages. As mentioned before, these utilities should be extracted to a shared module.
148-187: SamegetParseAsfunction issues as in other packages.The return type inconsistencies exist here as well.
packages/insight/src/client/client/types.ts (1)
1-223: Extract duplicated type definitions to a shared module.This file is identical to
packages/nebula/src/client/client/types.ts. Similar to the utility functions, these type definitions should be in a shared package to avoid duplication and ensure consistency across all client implementations.
🧹 Nitpick comments (13)
packages/nebula/src/configure.ts (2)
54-58: Minor TS-strictness: stay on the safe side whenoptionsis optionalInside the spread you dereference
options.authTokeneven thoughoptionsis typed as possiblyundefined.
Although control-flow narrowing usually saves you here, using the optional chain keeps the compiler silent understrictNullChecks+exactOptionalPropertyTypes.- ...(options?.authToken && { - authorization: `Bearer ${options.authToken}`, + ...(options?.authToken && { + authorization: `Bearer ${options?.authToken}`, }),
64-80: Samestringifyhelper duplicated in three packages
stringifyis now present verbatim inengine,nebula, andinsight. Extracting it to a small shared util (e.g.@thirdweb-dev/internal-json) avoids copy-pasta and keeps future fixes DRY.packages/engine/src/client/client.gen.ts (1)
8-8: Import path updated – good, but duplication spottedThe generator now targets
./client/index.js, consistent with the new local client.
However, identical client code has been generated into every package. A single shared internal package would cut bundle size and maintenance cost.packages/insight/src/client/client/client.ts (1)
12-15: Consider more specific typing for body parameter.The
body?: anytype could be more specific to improve type safety.-type ReqInit = Omit<RequestInit, "body" | "headers"> & { - body?: any; - headers: ReturnType<typeof mergeHeaders>; -}; +type ReqInit = Omit<RequestInit, "body" | "headers"> & { + body?: BodyInit | null | Record<string, unknown>; + headers: ReturnType<typeof mergeHeaders>; +};packages/insight/src/client/core/types.ts (1)
81-82: Fix documentation reference inconsistency.The comment mentions "native
paramsSerializer()Axios API function" but this is a fetch-based HTTP client, not Axios-based. This could confuse developers.- * This method will have no effect if the native `paramsSerializer()` Axios - * API function is used. + * This method will have no effect if a native query parameter serializer + * is used.packages/nebula/src/client/core/auth.ts (1)
35-37: Clarify basic auth token format expectations.The basic auth implementation uses
btoa(token)directly, which assumes the token is already in "username:password" format. Consider adding documentation to clarify this expectation or provide a helper function for combining username and password.if (auth.scheme === "basic") { + // Token should be in "username:password" format return `Basic ${btoa(token)}`; }packages/nebula/src/client/core/params.ts (2)
87-96: Consider resetting config variable for clarity.The
configvariable persists across iterations and may carry state from previous iterations. While this might be intentional behavior, it could be confusing.for (const [index, arg] of args.entries()) { + config = undefined; if (fields[index]) { config = fields[index]; }
66-72: Document the mutation behavior.The function mutates the input parameter object directly, which might be unexpected for callers.
+/** + * Removes empty slot objects from params in-place. + * @param params - The params object to modify + */ const stripEmptySlots = (params: Params) => {packages/nebula/src/client/core/bodySerializer.ts (1)
1-85: Address code duplication and approve implementation.This file is identical to
packages/insight/src/client/core/bodySerializer.ts. While the implementation is excellent with proper type handling, BigInt support, and array serialization, consider consolidating duplicate code across packages.The serialization logic is well-implemented:
- Proper type checking for FormData (string/Blob)
- BigInt handling for JSON compatibility
- Correct array element serialization
- Appropriate null/undefined filtering
packages/engine/src/client/client/client.ts (2)
164-170: Address TODO: Improve error handling and types.The TODO comment indicates that error handling and type definitions need improvement. Consider returning a consistent error structure.
Would you like me to generate an improved error handling implementation with better type safety?
17-189: Consider extracting shared client implementation.The client implementation appears to be duplicated across multiple packages (engine, nebula, insight). Consider extracting this to a shared package to follow DRY principles.
This would:
- Reduce maintenance burden
- Ensure consistency across packages
- Make updates easier to propagate
packages/engine/src/client/client/utils.ts (1)
205-219: Consider explicit case for "header" authentication.The switch statement handles "header" authentication through the default case. Consider making it explicit for clarity.
Apply this diff for better readability:
case "cookie": options.headers.append("Cookie", `${name}=${token}`); break; + case "header": default: options.headers.set(name, token); break;packages/engine/src/client/client/types.ts (1)
201-222: Overly complex legacy parser type may impact maintainabilityThe OptionsLegacyParser type uses deeply nested conditional logic that could be difficult to maintain and debug. Consider breaking this into smaller, more focused utility types.
Example refactor:
type HasBody<T> = T extends { body?: any } ? true : false; type HasHeaders<T> = T extends { headers?: any } ? true : false; type OptionsLegacyParser< TData = unknown, ThrowOnError extends boolean = boolean, TResponseStyle extends ResponseStyle = "fields", > = HasBody<TData> extends true ? HasHeaders<TData> extends true ? // both body and headers case : // only body case : HasHeaders<TData> extends true ? // only headers case : // neither case
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (48)
.changeset/little-items-allow.md(1 hunks)packages/engine/package.json(1 hunks)packages/engine/src/client/client.gen.ts(1 hunks)packages/engine/src/client/client/client.ts(1 hunks)packages/engine/src/client/client/index.ts(1 hunks)packages/engine/src/client/client/types.ts(1 hunks)packages/engine/src/client/client/utils.ts(1 hunks)packages/engine/src/client/core/auth.ts(1 hunks)packages/engine/src/client/core/bodySerializer.ts(1 hunks)packages/engine/src/client/core/params.ts(1 hunks)packages/engine/src/client/core/pathSerializer.ts(1 hunks)packages/engine/src/client/core/types.ts(1 hunks)packages/engine/src/client/sdk.gen.ts(14 hunks)packages/engine/src/client/types.gen.ts(5 hunks)packages/engine/src/configure.ts(1 hunks)packages/engine/tsconfig.base.json(1 hunks)packages/insight/package.json(1 hunks)packages/insight/src/client/client.gen.ts(1 hunks)packages/insight/src/client/client/client.ts(1 hunks)packages/insight/src/client/client/index.ts(1 hunks)packages/insight/src/client/client/types.ts(1 hunks)packages/insight/src/client/client/utils.ts(1 hunks)packages/insight/src/client/core/auth.ts(1 hunks)packages/insight/src/client/core/bodySerializer.ts(1 hunks)packages/insight/src/client/core/params.ts(1 hunks)packages/insight/src/client/core/pathSerializer.ts(1 hunks)packages/insight/src/client/core/types.ts(1 hunks)packages/insight/src/client/sdk.gen.ts(44 hunks)packages/insight/src/client/types.gen.ts(70 hunks)packages/insight/src/configure.ts(1 hunks)packages/insight/tsconfig.base.json(1 hunks)packages/nebula/openapi-ts.config.ts(1 hunks)packages/nebula/package.json(1 hunks)packages/nebula/src/client/client.gen.ts(1 hunks)packages/nebula/src/client/client/client.ts(1 hunks)packages/nebula/src/client/client/index.ts(1 hunks)packages/nebula/src/client/client/types.ts(1 hunks)packages/nebula/src/client/client/utils.ts(1 hunks)packages/nebula/src/client/core/auth.ts(1 hunks)packages/nebula/src/client/core/bodySerializer.ts(1 hunks)packages/nebula/src/client/core/params.ts(1 hunks)packages/nebula/src/client/core/pathSerializer.ts(1 hunks)packages/nebula/src/client/core/types.ts(1 hunks)packages/nebula/src/client/sdk.gen.ts(1 hunks)packages/nebula/src/client/types.gen.ts(3 hunks)packages/nebula/src/configure.ts(1 hunks)packages/nebula/tsconfig.base.json(1 hunks)packages/thirdweb/src/transaction/transaction-store.ts(1 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
`**/*.@(ts|tsx)`: Accept a typed 'props' object and export a named function (e.g., export function MyComponent()). Combine class names via 'cn', expose 'className' prop if useful. ...
**/*.@(ts|tsx): Accept a typed 'props' object and export a named function (e.g., export function MyComponent()).
Combine class names via 'cn', expose 'className' prop if useful.
Reuse core UI primitives; avoid re-implementing buttons, cards, modals.
Local state or effects live inside; data fetching happens in hooks.
Merge class names with 'cn' from '@/lib/utils' to keep conditional logic readable.
Stick to design-tokens: background ('bg-card'), borders ('border-border'), muted text ('text-muted-foreground') etc.
Use the 'container' class with a 'max-w-7xl' cap for page width consistency.
Spacing utilities ('px-', 'py-', 'gap-*') are preferred over custom margins.
Responsive helpers follow mobile-first ('max-sm', 'md', 'lg', 'xl').
Never hard-code colors – always go through Tailwind variables.
Tailwind CSS is the styling system – avoid inline styles or CSS modules.
Prefix files with 'import "server-only";' so they never end up in the client bundle (for server-only code).
packages/engine/src/configure.tspackages/engine/src/client/client.gen.tspackages/nebula/src/client/client.gen.tspackages/insight/src/client/client.gen.tspackages/nebula/src/configure.tspackages/nebula/openapi-ts.config.tspackages/insight/src/configure.tspackages/nebula/src/client/sdk.gen.tspackages/thirdweb/src/transaction/transaction-store.tspackages/nebula/src/client/core/types.tspackages/insight/src/client/client/client.tspackages/insight/src/client/client/index.tspackages/engine/src/client/core/types.tspackages/engine/src/client/types.gen.tspackages/insight/src/client/core/params.tspackages/engine/src/client/core/auth.tspackages/nebula/src/client/core/auth.tspackages/insight/src/client/core/types.tspackages/engine/src/client/sdk.gen.tspackages/insight/src/client/core/auth.tspackages/engine/src/client/core/params.tspackages/nebula/src/client/core/bodySerializer.tspackages/engine/src/client/client/index.tspackages/nebula/src/client/types.gen.tspackages/nebula/src/client/core/params.tspackages/insight/src/client/core/pathSerializer.tspackages/nebula/src/client/client/client.tspackages/nebula/src/client/client/index.tspackages/nebula/src/client/core/pathSerializer.tspackages/engine/src/client/core/bodySerializer.tspackages/engine/src/client/core/pathSerializer.tspackages/insight/src/client/core/bodySerializer.tspackages/nebula/src/client/client/utils.tspackages/nebula/src/client/client/types.tspackages/engine/src/client/client/utils.tspackages/insight/src/client/client/utils.tspackages/insight/src/client/client/types.tspackages/engine/src/client/client/client.tspackages/engine/src/client/client/types.tspackages/insight/src/client/types.gen.tspackages/insight/src/client/sdk.gen.ts
🧬 Code Graph Analysis (9)
packages/engine/src/client/core/types.ts (3)
packages/insight/src/client/core/types.ts (2)
Client(8-30)Config(32-98)packages/engine/src/client/core/auth.ts (2)
Auth(3-18)AuthToken(1-1)packages/engine/src/client/core/bodySerializer.ts (3)
BodySerializer(9-9)QuerySerializer(7-7)QuerySerializerOptions(11-15)
packages/insight/src/client/core/params.ts (4)
packages/engine/src/client/core/params.ts (4)
Field(3-13)Fields(15-18)FieldsConfig(20-20)buildClientParams(74-141)apps/dashboard/src/middleware.ts (1)
config(11-24)packages/engine/src/client/client/index.ts (1)
buildClientParams(8-8)packages/insight/src/client/client/index.ts (1)
buildClientParams(8-8)
packages/engine/src/client/sdk.gen.ts (1)
packages/engine/src/client/types.gen.ts (15)
ListAccountsResponses(129-146)CreateAccountResponses(166-183)WriteContractResponses(232-323)SendTransactionResponses(364-455)SignTransactionResponses(567-607)SignMessageResponses(644-684)SignTypedDataResponses(730-770)ReadContractResponses(815-827)GetNativeBalanceResponses(859-871)GetNativeBalanceErrors(848-857)EncodeFunctionDataResponses(912-953)SearchTransactionsResponses(972-1023)GetTransactionAnalyticsResponses(1041-1059)GetTransactionAnalyticsSummaryResponses(1087-1113)GetTransactionAnalyticsSummaryErrors(1076-1085)
packages/nebula/src/client/core/bodySerializer.ts (3)
packages/nebula/src/client/client/index.ts (4)
QuerySerializerOptions(2-2)formDataBodySerializer(4-4)jsonBodySerializer(5-5)urlSearchParamsBodySerializer(6-6)packages/nebula/src/client/core/pathSerializer.ts (3)
SerializerOptions(10-16)ArrayStyle(18-18)ObjectStyle(21-21)packages/vault-sdk/src/transaction-types.ts (1)
Blob(135-135)
packages/nebula/src/client/core/params.ts (2)
apps/dashboard/src/middleware.ts (1)
config(11-24)packages/nebula/src/client/client/index.ts (1)
buildClientParams(8-8)
packages/engine/src/client/core/pathSerializer.ts (1)
packages/insight/src/client/core/pathSerializer.ts (10)
SerializerOptions(10-16)ArrayStyle(18-18)ArraySeparatorStyle(19-19)ObjectStyle(21-21)separatorArrayExplode(28-39)separatorArrayNoExplode(41-52)separatorObjectExplode(54-65)serializeArrayParam(67-109)serializePrimitiveParam(111-127)serializeObjectParam(129-179)
packages/insight/src/client/core/bodySerializer.ts (5)
packages/engine/src/client/core/bodySerializer.ts (6)
QuerySerializer(7-7)BodySerializer(9-9)QuerySerializerOptions(11-15)formDataBodySerializer(37-56)jsonBodySerializer(58-63)urlSearchParamsBodySerializer(65-84)packages/engine/src/client/client/index.ts (4)
QuerySerializerOptions(2-2)formDataBodySerializer(4-4)jsonBodySerializer(5-5)urlSearchParamsBodySerializer(6-6)packages/insight/src/client/client/index.ts (4)
QuerySerializerOptions(2-2)formDataBodySerializer(4-4)jsonBodySerializer(5-5)urlSearchParamsBodySerializer(6-6)packages/engine/src/client/core/pathSerializer.ts (3)
SerializerOptions(10-16)ArrayStyle(18-18)ObjectStyle(21-21)packages/vault-sdk/src/transaction-types.ts (1)
Blob(135-135)
packages/engine/src/client/client/utils.ts (5)
packages/engine/src/client/core/pathSerializer.ts (5)
ArrayStyle(18-18)ArraySeparatorStyle(19-19)serializeArrayParam(67-109)serializeObjectParam(129-179)serializePrimitiveParam(111-127)packages/engine/src/client/client/index.ts (9)
QuerySerializerOptions(2-2)Config(13-13)RequestOptions(17-17)Client(11-11)mergeHeaders(22-22)Options(15-15)createConfig(22-22)ClientOptions(12-12)jsonBodySerializer(5-5)packages/engine/src/client/core/bodySerializer.ts (3)
QuerySerializerOptions(11-15)QuerySerializer(7-7)jsonBodySerializer(58-63)packages/engine/src/client/client/types.ts (5)
Config(10-59)RequestOptions(61-82)Client(165-167)Options(191-199)ClientOptions(129-133)packages/engine/src/client/core/auth.ts (1)
getAuthToken(20-40)
packages/insight/src/client/sdk.gen.ts (2)
packages/insight/src/client/types.gen.ts (6)
GetV1WebhooksResponses(32-60)GetV1WebhooksErrors(15-28)PostV1WebhooksResponses(124-152)PostV1WebhooksErrors(100-119)DeleteV1WebhooksByWebhookIdResponses(190-218)DeleteV1WebhooksByWebhookIdErrors(166-185)packages/insight/src/client/client/types.ts (1)
Options(191-199)
🪛 GitHub Actions: CI
packages/thirdweb/src/transaction/transaction-store.ts
[error] 87-87: TypeScript error TS2322: Type '{ chainId: string; receipt: { status: "success" | "failed"; to: string; }; transactionHash: 0x${string}; }[]' is not assignable to type 'StoredTransaction[]'.
🔇 Additional comments (58)
packages/insight/tsconfig.base.json (1)
24-24: LGTM: Necessary DOM.Iterable support added.The addition of
"DOM.Iterable"to the lib array is essential for supporting iterable DOM interfaces likeHeaders.entries()which are commonly used in HTTP client implementations. This change is consistent across all packages and aligns with the local client implementation effort.packages/engine/tsconfig.base.json (1)
24-24: LGTM: Consistent DOM.Iterable support added.The addition of
"DOM.Iterable"maintains consistency with other packages and provides necessary type support for iterable DOM interfaces used in the new HTTP client implementation.packages/nebula/tsconfig.base.json (1)
24-24: LGTM: Consistent DOM.Iterable support maintained.The addition of
"DOM.Iterable"is consistent across all packages and provides necessary type support for DOM iterable interfaces.packages/engine/src/client/core/types.ts (3)
1-6: LGTM: Well-structured imports for core dependencies.The imports correctly reference local modules for authentication and serialization types, aligning with the PR's objective to replace external dependencies with local implementations.
8-30: LGTM: Comprehensive Client interface with proper generics.The Client interface is well-designed with appropriate generic type parameters that allow for flexible implementations while maintaining type safety. The HTTP method coverage is complete and includes utility methods like
buildUrl,getConfig, andsetConfig.
32-98: LGTM: Comprehensive Config interface with excellent documentation.The Config interface provides excellent coverage of HTTP client configuration options including:
- Authentication with flexible token or function-based auth
- Request/response serialization and transformation
- Headers with flexible typing
- HTTP methods with proper constraints
- Query parameter serialization options
The JSDoc documentation is thorough and includes helpful links to MDN references.
packages/insight/src/configure.ts (1)
1-1: LGTM: Import path updated to use local client implementation.The change from external package
@hey-api/client-fetchto local module./client/client/index.jsaligns perfectly with the PR's objective to replace external dependencies with local implementations. This maintains the same functionality while providing better control over the client implementation.packages/engine/src/configure.ts (1)
1-1: ```shell
#!/bin/bashList all index.ts files under packages/engine/src/client
fd index.ts packages/engine/src/client
</details> <details> <summary>packages/nebula/src/configure.ts (1)</summary> `2-6`: **Local client import mirrors Engine – LGTM** Same rationale as the Engine package: the external dependency is gone and the local re-export keeps API parity. </details> <details> <summary>packages/insight/package.json (1)</summary> `32-32`: ```shell #!/bin/bash # Verify that pnpm-lock.yaml has been updated to 0.76.0 for @hey-api/openapi-ts rg -n '@hey-api/openapi-ts@' -g 'pnpm-lock.yaml' | grep -v '0.76.0'packages/nebula/src/client/client.gen.ts (1)
8-8: Verify local client implementation compatibility.The import has been successfully redirected from the external
@hey-api/client-fetchpackage to a local client implementation. Ensure that the local./client/index.jsmodule exports all the required types and functions (Config,createClient,createConfig,ClientOptions) with compatible interfaces.#!/bin/bash # Description: Verify that the local client module exports the required types and functions # Expected: Find the local client implementation with compatible exports # Check if the local client index file exists fd "index.js" --type f --full-path packages/nebula/src/client/client/ # Search for the exported functions and types in the local client implementation rg -A 5 "export.*createClient|export.*createConfig|export.*Config|export.*ClientOptions" packages/nebula/src/client/client/packages/engine/package.json (1)
32-32: Verify compatibility of hey-api version update.The update to
@hey-api/openapi-tsversion 0.76.0 should be verified for any breaking changes or compatibility issues with the current codebase generation.What are the breaking changes and new features in @hey-api/openapi-ts version 0.76.0 compared to 0.72.1?.changeset/little-items-allow.md (1)
1-8: Well-structured changeset documentation.The changeset properly documents the version updates across all affected packages with appropriate minor version bumps. The description clearly summarizes the hey-api version update.
packages/nebula/openapi-ts.config.ts (1)
4-6: Formatting improvement for consistency.The indentation standardization improves code consistency and readability without affecting functionality.
packages/nebula/src/client/sdk.gen.ts (1)
7-7: Consistent import redirection to local client.The import change aligns with the broader refactoring effort to replace external
@hey-api/client-fetchdependencies with local client implementations. This ensures consistency across the nebula package.packages/nebula/package.json (1)
36-36: LGTM: hey-api version upgrade aligns with PR objectives.The upgrade to
@hey-api/openapi-tsversion0.76.0is consistent with the PR goals.packages/nebula/src/client/types.gen.ts (3)
547-550: LGTM: Enhanced AgentResponse with summary field.The addition of the optional
summaryfield improves the API response structure while maintaining backward compatibility.
2277-2281: LGTM: Enhanced RegistryAgentListResponse with summary field.Consistent addition of the optional
summaryfield across response types is good for API consistency.
2277-2277: LGTM: Updated baseUrl to production endpoint.Changing the default
baseUrlfrom localhost to the production endpoint"https://nebula-api.thirdweb-dev.com"is appropriate for production usage.packages/engine/src/client/sdk.gen.ts (3)
7-7: LGTM: Migrated to local client implementation.The import change from the external
@hey-api/client-fetchpackage to the local./client/index.jsmodule aligns with the PR objective to replace external dependencies with local implementations.
11-37: LGTM: Updated type imports to use pluralized forms.The systematic change from singular response type names (e.g.,
CreateAccountResponse) to plural forms (e.g.,CreateAccountResponses) is consistent with the new local client implementation. The addition of error types for some functions also improves error handling capabilities.
65-403: LGTM: Updated generic type parameters consistently.All HTTP client method calls have been updated to use the new pluralized response types and error types where applicable. The changes are systematic and maintain the same function signatures and behavior.
packages/engine/src/client/core/auth.ts (1)
1-41: LGTM: Well-structured authentication module.This new authentication module provides comprehensive support for different authentication schemes and token retrieval methods:
- Flexible auth configuration with support for headers, query params, and cookies
- Proper handling of bearer and basic authentication schemes
- Async token retrieval support through callbacks
- Clean separation of concerns for authentication logic
The implementation correctly handles token encoding for basic auth using
btoa()and proper formatting for bearer tokens.packages/engine/src/client/types.gen.ts (5)
21-23: LGTM! Excellent documentation addition.The JSDoc comment clearly explains the auto-execution behavior and provides guidance on when to use other execution options.
43-45: LGTM! Clear documentation for ERC4337 execution.The JSDoc comment properly identifies this as the Smart Account execution option.
80-82: LGTM! Well-documented zkSync execution options.The JSDoc comment clearly explains the zkSync native AA execution and its chain-specific limitations.
139-139: LGTM! Useful addition of optional label property.The optional
labelproperty enhances account management by allowing human-readable identifiers alongside addresses.
176-176: LGTM! Consistent label property addition.The optional
labelproperty in CreateAccountResponses maintains consistency with ListAccountsResponses.packages/insight/src/client/core/auth.ts (1)
1-41: LGTM! Well-designed authentication module.The auth module provides a clean, flexible interface for handling different authentication schemes:
- Comprehensive
Authinterface with sensible defaults- Proper token formatting for bearer and basic schemes
- Correct use of
btoa()for basic auth encoding- Support for both callback and direct token values
The implementation is type-safe and handles edge cases appropriately.
packages/insight/src/client/client/index.ts (1)
1-23: LGTM! Well-organized client API consolidation.The index file provides a clean, comprehensive public API surface by re-exporting:
- Core authentication and serialization types
- Body serializer functions for different content types
- Main client creation function and related types
- Configuration and utility functions
The modular structure and .js import extensions are appropriate for ESM compatibility.
packages/nebula/src/client/client/index.ts (1)
1-23: LGTM! Consistent client architecture across packages.The index file mirrors the structure of the insight package, providing the same comprehensive API surface. This consistency across packages (
engine,insight,nebula) enhances maintainability and provides a uniform developer experience.packages/insight/src/client/client/client.ts (4)
72-75: LGTM! Correct fetch assignment pattern.The comment and fetch assignment pattern correctly prevents the "Illegal invocation" TypeError that occurs when fetch is called without proper context binding.
53-56: LGTM! Proper Content-Type header management.Removing the Content-Type header for empty bodies prevents invalid requests and follows HTTP best practices.
88-99: LGTM! Proper handling of no-content responses.The logic correctly handles 204 No Content responses and zero-length content, returning empty objects based on the response style preference.
173-189: LGTM! Comprehensive HTTP client interface.The client provides all standard HTTP methods with consistent options handling and exposes useful utilities like
buildUrl, configuration management, and interceptors.packages/engine/src/client/client/index.ts (1)
1-22: Well-structured API consolidation.The index file properly consolidates the client package's public API with logical grouping of exports. The separation between types and functions is clear and the imports are well-organized.
packages/insight/src/client/core/bodySerializer.ts (3)
17-23: Good type handling for FormData serialization.The implementation correctly handles different value types - strings and Blobs are appended directly while other values are JSON-stringified. This ensures proper FormData compatibility.
58-63: Excellent BigInt handling for JSON compatibility.The JSON serializer properly converts BigInt values to strings using a replacer function, preventing JSON serialization errors.
43-52: Proper array serialization strategy.The array handling correctly serializes each element separately, which is the expected behavior for form data and query parameters.
packages/engine/src/client/client/client.ts (1)
72-75: Good handling of fetch assignment.The non-null assertion is safe here since
opts.fetchis guaranteed to have a value from the fallback chain on line 38. The comment explaining the assignment pattern is helpful.packages/insight/src/client/core/pathSerializer.ts (1)
1-179: Well-implemented OpenAPI parameter serialization.The implementation correctly handles all OpenAPI serialization styles with proper encoding and error handling. The code is well-structured and type-safe.
packages/nebula/src/client/client/types.ts (1)
1-223: Well-structured type definitions for the Nebula client.The type definitions are comprehensive and properly documented, providing good TypeScript support for the HTTP client functionality.
packages/engine/src/client/client/types.ts (5)
1-6: LGTM: Clean import structureThe import statements are well-organized and follow proper TypeScript conventions with type-only imports.
8-8: LGTM: Clear response style enumerationThe ResponseStyle union type clearly defines the two supported response formats.
10-59: Good interface design with clear documentationThe Config interface is well-structured with comprehensive JSDoc documentation. The intentional
next?: neverproperty effectively prevents misuse in Next.js applications.
165-167: Well-designed client interface extensionThe Client type properly extends the CoreClient while adding the interceptors functionality. The middleware typing is appropriate for request/response processing.
177-179: Excellent configuration factory patternThe CreateClientConfig type and its documentation clearly explain the intended usage pattern for client initialization, particularly for Next.js applications.
packages/insight/src/client/types.gen.ts (5)
1221-1222: Appropriate type changes for blockchain numeric valuesThe conversion of transaction value fields (
value,gas_price,max_fee_per_gas, etc.) and signature components (r,s,v) fromnumbertostringis correct. These values can exceed JavaScript's safe integer range and should be handled as strings to prevent precision loss.Also applies to: 1226-1227, 1229-1231, 1237-1237, 1239-1239, 1485-1486, 1490-1491, 1493-1495, 1501-1501, 1503-1503, 1739-1740, 1744-1745, 1747-1749, 1755-1755, 1757-1757
1233-1233: Support for EIP-7702 authorization listsThe addition of
authorization_list_jsonalongsideaccess_list_jsonappears to add support for EIP-7702 (Set EOA account code). This is a backward-compatible addition as the field is optional.Also applies to: 1325-1325, 1497-1497, 1751-1751, 3325-3325, 5446-5446
1921-1950: Well-structured price data enhancementsThe addition of
price_dataobjects provides comprehensive token pricing information including USD price, volume, market cap, supply metrics, and price changes. The structure is consistent across all token-related endpoints and the fields are appropriately optional.Also applies to: 2011-2040, 2142-2171, 2232-2261, 2394-2423, 2484-2513, 2702-2731, 3193-3222
2336-2359: Enhanced filtering capabilities with ENS supportThe new query parameters add valuable filtering options:
- Block timestamp filters for time-based queries
- Transfer type filtering (mint/transfer/burn/sale)
- Contract address array filtering
- Sort order control
The JSDoc annotations indicating ENS support are helpful.
Verify that the backend properly handles ENS resolution for these address parameters:
Does the thirdweb Insight API support ENS (Ethereum Name Service) resolution for address parameters in API endpoints?Also applies to: 4197-4227
541-541: Verify block_number and block_timestamp type changesThe
block_numberandblock_timestampfields have been changed fromstringtonumber. While these values typically fit within JavaScript's safe integer range, please confirm this change is intentional and won't cause issues with very large block numbers on some chains.#!/bin/bash # Check current usage of block_number and block_timestamp rg -A 2 -B 2 "block_number|block_timestamp" --type ts --type tsx | grep -E "(parseInt|Number\(|\.toString\(\)|as string)" | head -20 # Look for any comparisons or operations that might be affected ast-grep --pattern 'parseInt($_.block_number)' ast-grep --pattern '$_.block_number.toString()'Also applies to: 543-543, 755-755, 757-757, 966-966, 968-968, 1213-1213, 1215-1215
packages/insight/src/client/sdk.gen.ts (6)
3-7: LGTM: Import source migration to local moduleThe import change from
@hey-api/client-fetchto the local./client/index.jsmodule is consistent with the broader refactoring effort to move client functionality from external dependencies to local implementations.
9-133: LGTM: Consistent type renaming from singular to plural formsThe systematic renaming of all response and error types from singular (e.g.,
GetV1WebhooksResponse) to plural forms (e.g.,GetV1WebhooksResponses) is consistent throughout the import statements. This aligns with the new client structure and naming conventions.
156-173: LGTM: Function implementation correctly updated with new type parametersThe
getV1Webhooksfunction properly uses the new pluralized typesGetV1WebhooksResponsesandGetV1WebhooksErrorsin its generic type parameters, maintaining type safety while adapting to the new client structure.
251-251: LGTM: Header spreading cleanupThe removal of optional chaining (
...options?.headers→...options.headers) is appropriate since theoptionsparameter is required in this context (options: Options<...>), making the optional chaining unnecessary.
534-534: LGTM: Appropriate deprecation annotationsThe addition of
@deprecatedJSDoc comments for the ERC-20, ERC-721, and ERC-1155 balance endpoints aligns with the API comments indicating these endpoints are being deprecated in favor of newer alternatives (/tokensand/nfts/balance).Also applies to: 583-583, 609-609
821-821: LGTM: Consistent header spreading cleanupSimilar to line 251, the removal of optional chaining in the headers spreading is appropriate since
optionsis a required parameter in this function context.
| import type { Auth, AuthToken } from "./auth.js"; | ||
| import type { | ||
| BodySerializer, | ||
| QuerySerializer, | ||
| QuerySerializerOptions, | ||
| } from "./bodySerializer.js"; | ||
|
|
||
| export interface Client< | ||
| RequestFn = never, | ||
| Config = unknown, | ||
| MethodFn = never, | ||
| BuildUrlFn = never, | ||
| > { | ||
| /** | ||
| * Returns the final request URL. | ||
| */ | ||
| buildUrl: BuildUrlFn; | ||
| connect: MethodFn; | ||
| delete: MethodFn; | ||
| get: MethodFn; | ||
| getConfig: () => Config; | ||
| head: MethodFn; | ||
| options: MethodFn; | ||
| patch: MethodFn; | ||
| post: MethodFn; | ||
| put: MethodFn; | ||
| request: RequestFn; | ||
| setConfig: (config: Config) => Config; | ||
| trace: MethodFn; | ||
| } | ||
|
|
||
| export interface Config { | ||
| /** | ||
| * Auth token or a function returning auth token. The resolved value will be | ||
| * added to the request payload as defined by its `security` array. | ||
| */ | ||
| auth?: ((auth: Auth) => Promise<AuthToken> | AuthToken) | AuthToken; | ||
| /** | ||
| * A function for serializing request body parameter. By default, | ||
| * {@link JSON.stringify()} will be used. | ||
| */ | ||
| bodySerializer?: BodySerializer | null; | ||
| /** | ||
| * An object containing any HTTP headers that you want to pre-populate your | ||
| * `Headers` object with. | ||
| * | ||
| * {@link https://developer.mozilla.org/docs/Web/API/Headers/Headers#init See more} | ||
| */ | ||
| headers?: | ||
| | RequestInit["headers"] | ||
| | Record< | ||
| string, | ||
| | string | ||
| | number | ||
| | boolean | ||
| | (string | number | boolean)[] | ||
| | null | ||
| | undefined | ||
| | unknown | ||
| >; | ||
| /** | ||
| * The request method. | ||
| * | ||
| * {@link https://developer.mozilla.org/docs/Web/API/fetch#method See more} | ||
| */ | ||
| method?: | ||
| | "CONNECT" | ||
| | "DELETE" | ||
| | "GET" | ||
| | "HEAD" | ||
| | "OPTIONS" | ||
| | "PATCH" | ||
| | "POST" | ||
| | "PUT" | ||
| | "TRACE"; | ||
| /** | ||
| * A function for serializing request query parameters. By default, arrays | ||
| * will be exploded in form style, objects will be exploded in deepObject | ||
| * style, and reserved characters are percent-encoded. | ||
| * | ||
| * This method will have no effect if the native `paramsSerializer()` Axios | ||
| * API function is used. | ||
| * | ||
| * {@link https://swagger.io/docs/specification/serialization/#query View examples} | ||
| */ | ||
| querySerializer?: QuerySerializer | QuerySerializerOptions; | ||
| /** | ||
| * A function transforming response data before it's returned. This is useful | ||
| * for post-processing data, e.g. converting ISO strings into Date objects. | ||
| */ | ||
| responseTransformer?: (data: unknown) => Promise<unknown>; | ||
| /** | ||
| * A function validating response data. This is useful if you want to ensure | ||
| * the response conforms to the desired shape, so it can be safely passed to | ||
| * the transformers and returned to the user. | ||
| */ | ||
| responseValidator?: (data: unknown) => Promise<unknown>; | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Consider consolidating duplicate code across packages.
This file is identical to packages/insight/src/client/core/types.ts. Consider extracting common types to a shared module to reduce duplication and improve maintainability.
You could create a shared core types package or move common types to a shared location that both packages can import from.
🤖 Prompt for AI Agents
In packages/nebula/src/client/core/types.ts lines 1 to 98, the types defined
here are identical to those in packages/insight/src/client/core/types.ts,
causing code duplication. To fix this, extract the common types into a new
shared module or package that both nebula and insight can import from. Then,
update both packages to import these types from the shared location instead of
duplicating the code.
| export const buildClientParams = ( | ||
| args: ReadonlyArray<unknown>, | ||
| fields: FieldsConfig, | ||
| ) => { | ||
| const params: Params = { | ||
| body: {}, | ||
| headers: {}, | ||
| path: {}, | ||
| query: {}, | ||
| }; | ||
|
|
||
| const map = buildKeyMap(fields); | ||
|
|
||
| let config: FieldsConfig[number] | undefined; | ||
|
|
||
| for (const [index, arg] of args.entries()) { | ||
| if (fields[index]) { | ||
| config = fields[index]; | ||
| } | ||
|
|
||
| if (!config) { | ||
| continue; | ||
| } | ||
|
|
||
| if ("in" in config) { | ||
| if (config.key) { | ||
| const field = map.get(config.key)!; | ||
| const name = field.map || config.key; | ||
| (params[field.in] as Record<string, unknown>)[name] = arg; | ||
| } else { | ||
| params.body = arg; | ||
| } | ||
| } else { | ||
| for (const [key, value] of Object.entries(arg ?? {})) { | ||
| const field = map.get(key); | ||
|
|
||
| if (field) { | ||
| const name = field.map || key; | ||
| (params[field.in] as Record<string, unknown>)[name] = value; | ||
| } else { | ||
| const extra = extraPrefixes.find(([prefix]) => | ||
| key.startsWith(prefix), | ||
| ); | ||
|
|
||
| if (extra) { | ||
| const [prefix, slot] = extra; | ||
| (params[slot] as Record<string, unknown>)[ | ||
| key.slice(prefix.length) | ||
| ] = value; | ||
| } else { | ||
| for (const [slot, allowed] of Object.entries( | ||
| config.allowExtra ?? {}, | ||
| )) { | ||
| if (allowed) { | ||
| (params[slot as Slot] as Record<string, unknown>)[key] = value; | ||
| break; | ||
| } | ||
| } | ||
| } | ||
| } | ||
| } | ||
| } | ||
| } | ||
|
|
||
| stripEmptySlots(params); | ||
|
|
||
| return params; | ||
| }; |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Consider consolidating duplicate parameter building logic.
This buildClientParams function appears to be duplicated across multiple packages (insight, engine, nebula). Consider extracting this shared logic to a common utility to reduce code duplication and improve maintainability.
Based on the relevant code snippets, the engine package contains nearly identical implementation. Consider creating a shared utility package or moving this logic to a common location.
🤖 Prompt for AI Agents
In packages/insight/src/client/core/params.ts around lines 74 to 141, the
buildClientParams function duplicates logic found in other packages like engine
and nebula. To fix this, extract the buildClientParams function into a shared
utility module accessible by all packages. Then, replace the duplicated
implementations in each package with imports from this common utility, ensuring
consistent behavior and easier maintenance.
| const field = map.get(config.key)!; | ||
| const name = field.map || config.key; | ||
| (params[field.in] as Record<string, unknown>)[name] = arg; |
There was a problem hiding this comment.
Remove unsafe non-null assertion operator.
The non-null assertion operator could cause runtime errors if the key doesn't exist in the map. Add proper error handling or validation.
- const field = map.get(config.key)!;
- const name = field.map || config.key;
- (params[field.in] as Record<string, unknown>)[name] = arg;
+ const field = map.get(config.key);
+ if (!field) {
+ throw new Error(`Invalid field key: ${config.key}`);
+ }
+ const name = field.map || config.key;
+ (params[field.in] as Record<string, unknown>)[name] = arg;📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| const field = map.get(config.key)!; | |
| const name = field.map || config.key; | |
| (params[field.in] as Record<string, unknown>)[name] = arg; | |
| const field = map.get(config.key); | |
| if (!field) { | |
| throw new Error(`Invalid field key: ${config.key}`); | |
| } | |
| const name = field.map || config.key; | |
| (params[field.in] as Record<string, unknown>)[name] = arg; |
🤖 Prompt for AI Agents
In packages/insight/src/client/core/params.ts around lines 100 to 102, the code
uses a non-null assertion operator on map.get(config.key), which can cause
runtime errors if the key is not found. Replace the non-null assertion with a
check to verify that the key exists in the map before accessing it. If the key
is missing, handle the error appropriately, such as throwing an error or
returning early, to ensure safe access and prevent runtime exceptions.
| } | ||
| } | ||
|
|
||
| finalError = finalError || ({} as string); |
There was a problem hiding this comment.
Fix type casting issue with error fallback.
The code casts an empty object as a string, which is incorrect and could lead to runtime type errors.
Apply this diff to fix the type casting:
- finalError = finalError || ({} as string);
+ finalError = finalError || "";Alternatively, if you need to preserve object errors:
- finalError = finalError || ({} as string);
+ finalError = finalError || {};📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| finalError = finalError || ({} as string); | |
| finalError = finalError || ""; |
🤖 Prompt for AI Agents
In packages/engine/src/client/client/client.ts at line 158, the code incorrectly
casts an empty object as a string for the error fallback, which can cause
runtime type errors. Replace the fallback with an empty string literal or a
valid string value instead of casting an object to a string to ensure type
safety and prevent errors.
| ["application/", "audio/", "image/", "video/"].some((type) => | ||
| cleanContent.startsWith(type), | ||
| ) | ||
| ) { | ||
| return "blob"; | ||
| } | ||
|
|
||
| if (cleanContent.startsWith("text/")) { | ||
| return "text"; | ||
| } | ||
|
|
||
| return; | ||
| }; |
There was a problem hiding this comment.
Fix missing return value at the end of getParseAs function.
The function returns undefined at line 186, but this doesn't match the declared return type.
Apply this diff to provide a default return value:
- return;
+ return "stream";📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| ["application/", "audio/", "image/", "video/"].some((type) => | |
| cleanContent.startsWith(type), | |
| ) | |
| ) { | |
| return "blob"; | |
| } | |
| if (cleanContent.startsWith("text/")) { | |
| return "text"; | |
| } | |
| return; | |
| }; | |
| ["application/", "audio/", "image/", "video/"].some((type) => | |
| cleanContent.startsWith(type), | |
| ) | |
| ) { | |
| return "blob"; | |
| } | |
| if (cleanContent.startsWith("text/")) { | |
| return "text"; | |
| } | |
| return "stream"; | |
| }; |
🤖 Prompt for AI Agents
In packages/engine/src/client/client/utils.ts around lines 175 to 187, the
function getParseAs ends with an implicit undefined return which does not match
its declared return type. Fix this by explicitly returning a default value
consistent with the return type at the end of the function instead of returning
undefined.
| export const getParseAs = ( | ||
| contentType: string | null, | ||
| ): Exclude<Config["parseAs"], "auto"> => { | ||
| if (!contentType) { | ||
| // If no Content-Type header is provided, the best we can do is return the raw response body, | ||
| // which is effectively the same as the 'stream' option. | ||
| return "stream"; | ||
| } | ||
|
|
||
| const cleanContent = contentType.split(";")[0]?.trim(); | ||
|
|
||
| if (!cleanContent) { | ||
| return; | ||
| } | ||
|
|
There was a problem hiding this comment.
Fix inconsistent return type in getParseAs function.
The function can return undefined at line 160, but the return type excludes it.
Apply this diff to fix the return type:
-): Exclude<Config["parseAs"], "auto"> => {
+): Exclude<Config["parseAs"], "auto"> | undefined => {📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| export const getParseAs = ( | |
| contentType: string | null, | |
| ): Exclude<Config["parseAs"], "auto"> => { | |
| if (!contentType) { | |
| // If no Content-Type header is provided, the best we can do is return the raw response body, | |
| // which is effectively the same as the 'stream' option. | |
| return "stream"; | |
| } | |
| const cleanContent = contentType.split(";")[0]?.trim(); | |
| if (!cleanContent) { | |
| return; | |
| } | |
| export const getParseAs = ( | |
| contentType: string | null, | |
| ): Exclude<Config["parseAs"], "auto"> | undefined => { | |
| if (!contentType) { | |
| // If no Content-Type header is provided, the best we can do is return the raw response body, | |
| // which is effectively the same as the 'stream' option. | |
| return "stream"; | |
| } | |
| const cleanContent = contentType.split(";")[0]?.trim(); | |
| if (!cleanContent) { | |
| return; | |
| } | |
| // …rest of function… |
🤖 Prompt for AI Agents
In packages/engine/src/client/client/utils.ts around lines 148 to 162, the
getParseAs function currently returns undefined when cleanContent is falsy, but
the declared return type excludes undefined. To fix this, update the function to
always return a valid value matching the declared return type by replacing the
undefined return with a default valid return such as "stream" or another
appropriate value consistent with the return type.
| export type RequestResult< | ||
| TData = unknown, | ||
| TError = unknown, | ||
| ThrowOnError extends boolean = boolean, | ||
| TResponseStyle extends ResponseStyle = "fields", | ||
| > = ThrowOnError extends true | ||
| ? Promise< | ||
| TResponseStyle extends "data" | ||
| ? TData extends Record<string, unknown> | ||
| ? TData[keyof TData] | ||
| : TData | ||
| : { | ||
| data: TData extends Record<string, unknown> | ||
| ? TData[keyof TData] | ||
| : TData; | ||
| request: Request; | ||
| response: Response; | ||
| } | ||
| > | ||
| : Promise< | ||
| TResponseStyle extends "data" | ||
| ? | ||
| | (TData extends Record<string, unknown> | ||
| ? TData[keyof TData] | ||
| : TData) | ||
| | undefined | ||
| : ( | ||
| | { | ||
| data: TData extends Record<string, unknown> | ||
| ? TData[keyof TData] | ||
| : TData; | ||
| error: undefined; | ||
| } | ||
| | { | ||
| data: undefined; | ||
| error: TError extends Record<string, unknown> | ||
| ? TError[keyof TError] | ||
| : TError; | ||
| } | ||
| ) & { | ||
| request: Request; | ||
| response: Response; | ||
| } | ||
| >; |
There was a problem hiding this comment.
Complex conditional type may have unpredictable data extraction
The RequestResult type contains potentially problematic data extraction logic:
TData extends Record<string, unknown> ? TData[keyof TData] : TDataThis pattern extracts a value using keyof TData, but if TData has multiple properties, the result is unpredictable since keyof TData returns a union of all keys.
Consider these alternatives:
- If you need the first property value, use a more explicit extraction method
- If you need all properties, return the entire object
- Add constraints to ensure TData has only one property
- TData extends Record<string, unknown>
- ? TData[keyof TData]
- : TData
+ TData extends Record<string, unknown>
+ ? TData extends Record<infer K, infer V>
+ ? K extends string
+ ? V
+ : TData
+ : TData
+ : TData🤖 Prompt for AI Agents
In packages/engine/src/client/client/types.ts between lines 84 and 127, the
RequestResult type uses TData[keyof TData] to extract a value, which is
unpredictable if TData has multiple properties because keyof TData is a union of
keys. To fix this, clarify the intent by either restricting TData to a
single-property object, explicitly extracting the first property value using a
helper type or utility, or returning the entire TData object instead of a single
property value. Adjust the conditional type accordingly to ensure consistent and
predictable data extraction.
| @@ -536,10 +537,10 @@ export type GetV1EventsResponses = { | |||
| */ | |||
| 200: { | |||
| data?: Array<{ | |||
| chain_id: number; | |||
| block_number: string; | |||
| chain_id: string; | |||
There was a problem hiding this comment.
❓ Verification inconclusive
Breaking change: chain_id type changed from number to string
The chain_id field has been changed from number to string across multiple response types. This is a breaking change that could impact existing consumers expecting numeric chain IDs.
Please verify if this type change is intentional and consistent with the backend API implementation:
Also applies to: 754-754, 965-965, 1212-1212, 1304-1304, 1336-1336, 1425-1425, 1476-1476, 1730-1730, 3304-3304, 3336-3336, 5425-5425
🏁 Script executed:
#!/bin/bash
# Check if there are any usages of chain_id that might be affected by this type change
# Search for chain_id usage in the codebase
rg -A 3 -B 3 "chain_id" --type ts --type tsx | grep -E "(chain_id.*:.*number|\.chain_id|chain_id\])" | head -20
# Check if there are any type assertions or comparisons that might break
ast-grep --pattern 'chain_id === $_'
ast-grep --pattern 'chain_id == $_'
ast-grep --pattern '$_.chain_id as number'Length of output: 261
Breaking change: chain_id type changed from number to string
The chain_id field has been changed from number to string across multiple response types. This is a breaking change that could impact existing consumers expecting numeric chain IDs.
Please verify if this type change is intentional and consistent with the backend API implementation:
#!/bin/bash
# Check if there are any usages of chain_id that might be affected by this type change
# Search for chain_id usage in the codebase
rg -A 3 -B 3 "chain_id" --type ts --type tsx | grep -E "(chain_id.*:.*number|\.chain_id|chain_id\])" | head -20
# Check if there are any type assertions or comparisons that might break
ast-grep --pattern 'chain_id === $_'
ast-grep --pattern 'chain_id == $_'
ast-grep --pattern '$_.chain_id as number'Also applies to: 754-754, 965-965, 1212-1212, 1304-1304, 1336-1336, 1425-1425, 1476-1476, 1730-1730, 3304-3304, 3336-3336, 5425-5425
🤖 Prompt for AI Agents
In packages/insight/src/client/types.gen.ts at line 540 and similarly at lines
754, 965, 1212, 1304, 1336, 1425, 1476, 1730, 3304, 3336, and 5425, the type of
the chain_id field has been changed from number to string. Verify this change is
intentional by confirming it matches the backend API specification. Then, update
all related code usages, type assertions, and comparisons involving chain_id to
handle it as a string instead of a number to prevent type errors and runtime
issues.
<!--
## title your PR with this format: "[SDK/Dashboard/Portal] Feature/Fix: Concise title for the changes"
If you did not copy the branch name from Linear, paste the issue tag here (format is TEAM-0000):
## Notes for the reviewer
Anything important to call out? Be sure to also clarify these in your comments.
## How to test
Unit tests, playground, etc.
-->
This PR updates the version of the `@hey-api/openapi-ts` package to `0.76.0` in the `@thirdweb-dev/engine`, `@thirdweb-dev/insight` and `@thirdweb-dev/nebula` packages. Also, it adds a check in the `chain_id` in the `thirdweb` package in case it gets returned as a string and not as a number.
<!-- start pr-codex -->
---
## PR-Codex overview
This PR focuses on updating various packages with minor version changes, enhancing type definitions, and improving request handling in the client libraries. It also includes adjustments to configuration files and serialization methods.
### Detailed summary
- Updated `limit` in `.size-limit.json` from `65 kB` to `68 kB`.
- Updated dependencies in `package.json` files for `@hey-api/openapi-ts` to `0.76.0`.
- Added type definitions for `Auth` and `Config` in client libraries.
- Enhanced request handling in `createClient` function.
- Improved serialization methods in `bodySerializer`.
- Updated response interfaces for various API methods to reflect new response types.
> The following files were skipped due to too many changes: `packages/engine/src/client/client/types.ts`, `packages/nebula/src/client/client/types.ts`, `packages/insight/src/client/client/types.ts`, `packages/nebula/src/client/client/utils.ts`, `packages/insight/src/client/client/utils.ts`, `packages/engine/src/client/client/utils.ts`, `packages/insight/src/client/sdk.gen.ts`, `pnpm-lock.yaml`, `packages/insight/src/client/types.gen.ts`
> ✨ Ask PR-Codex anything about this PR by commenting with `/codex {your question}`
<!-- end pr-codex -->
<!-- This is an auto-generated comment: release notes by coderabbit.ai -->
## Summary by CodeRabbit
- **New Features**
- Introduced fully configurable HTTP client modules with request/response interceptors, authentication, serialization, and flexible response parsing across multiple packages.
- Added centralized utility modules for body and query serialization, URL construction, and middleware/interceptor management.
- Expanded comprehensive type definitions for client configuration, request options, response handling, and parameter mapping.
- **Enhancements**
- Improved API type safety with extended filtering options, detailed address documentation, and enriched price data in responses.
- Added support for new response styles and configurable error handling.
- Updated default API endpoints and enhanced type documentation.
- **Bug Fixes**
- Ensured consistent numeric types for fields like `chain_id`, `block_number`, and transaction values across APIs.
- Fixed transaction history mapping to guarantee numeric `chainId`.
- **Chores**
- Upgraded dependencies including "hey-api" and related packages; removed deprecated fields and cleaned type definitions.
- Updated TypeScript configurations to include iterable DOM interfaces for better typings.
- **Style**
- Standardized code formatting and indentation in configuration files.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
graphite-app
bot
force-pushed
the
pr/update-nebula-package-responses
branch
from
5ec35e1 to
74e1f14
Compare
graphite-app
bot
removed
the
merge-queue
There was a problem hiding this comment.
Actionable comments posted: 4
🔭 Outside diff range comments (1)
packages/nebula/src/client/client/types.ts (1)
1-223: Ensure consistent fixes across all packages.The type definitions are nearly identical to the engine and insight packages. When fixing the
RequestResulttype issue, ensure the same fix is applied consistently across all three packages (engine, insight, nebula) to maintain uniformity.
♻️ Duplicate comments (5)
packages/insight/src/client/client/client.ts (1)
142-171: Error handling needs type improvements.The error handling logic has the same type safety concerns identified in previous reviews: casting objects as strings and inconsistent error type handling.
packages/engine/src/client/client/client.ts (1)
158-158: Fix type casting issue with error fallback.The same type casting issue exists here as flagged in previous reviews - casting empty object as string.
packages/engine/src/client/client/utils.ts (1)
148-187: Fix missing return type to include undefined.The function can return
undefinedat lines 160 and 186, but the return type doesn't includeundefined.packages/insight/src/client/client/utils.ts (1)
148-187: Fix missing return type to include undefined.The function can return
undefinedat lines 160 and 186, but the return type doesn't includeundefined.packages/engine/src/client/client/types.ts (1)
84-127: Complex conditional type may have unpredictable data extraction.The
TData[keyof TData]pattern used for data extraction can be unpredictable when TData has multiple properties, as previously identified.
🧹 Nitpick comments (3)
packages/engine/src/client/core/pathSerializer.ts (1)
120-124: Improve error message and type handling.The error handling for nested objects could be more informative and the type checking more robust.
Consider this improvement:
if (typeof value === "object") { throw new Error( - "Deeply-nested arrays/objects aren't supported. Provide your own `querySerializer()` to handle these.", + `Deeply-nested arrays/objects aren't supported for parameter "${name}". Provide your own querySerializer() to handle these.`, ); }packages/engine/src/client/client/utils.ts (1)
189-223: Clarify early return behavior in authentication loop.The function returns early at line 221 after processing the first authentication token, which means subsequent security items in the array won't be processed. If this "first match wins" behavior is intentional, consider adding a comment to clarify this design decision.
for (const auth of security) { const token = await getAuthToken(auth, options.auth); if (!token) { continue; } const name = auth.name ?? "Authorization"; switch (auth.in) { case "query": if (!options.query) { options.query = {}; } options.query[name] = token; break; case "cookie": options.headers.append("Cookie", `${name}=${token}`); break; case "header": default: options.headers.set(name, token); break; } + // Process only the first valid authentication token return; }packages/insight/src/client/client/utils.ts (1)
189-222: Clarify early return behavior in authentication loop.The function returns early at line 220 after processing the first authentication token, preventing subsequent security items from being processed. Consider documenting this "first match wins" behavior if intentional.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (49)
.changeset/little-items-allow.md(1 hunks)packages/engine/package.json(1 hunks)packages/engine/src/client/client.gen.ts(1 hunks)packages/engine/src/client/client/client.ts(1 hunks)packages/engine/src/client/client/index.ts(1 hunks)packages/engine/src/client/client/types.ts(1 hunks)packages/engine/src/client/client/utils.ts(1 hunks)packages/engine/src/client/core/auth.ts(1 hunks)packages/engine/src/client/core/bodySerializer.ts(1 hunks)packages/engine/src/client/core/params.ts(1 hunks)packages/engine/src/client/core/pathSerializer.ts(1 hunks)packages/engine/src/client/core/types.ts(1 hunks)packages/engine/src/client/sdk.gen.ts(14 hunks)packages/engine/src/client/types.gen.ts(5 hunks)packages/engine/src/configure.ts(1 hunks)packages/engine/tsconfig.base.json(1 hunks)packages/insight/package.json(1 hunks)packages/insight/src/client/client.gen.ts(1 hunks)packages/insight/src/client/client/client.ts(1 hunks)packages/insight/src/client/client/index.ts(1 hunks)packages/insight/src/client/client/types.ts(1 hunks)packages/insight/src/client/client/utils.ts(1 hunks)packages/insight/src/client/core/auth.ts(1 hunks)packages/insight/src/client/core/bodySerializer.ts(1 hunks)packages/insight/src/client/core/params.ts(1 hunks)packages/insight/src/client/core/pathSerializer.ts(1 hunks)packages/insight/src/client/core/types.ts(1 hunks)packages/insight/src/client/sdk.gen.ts(44 hunks)packages/insight/src/client/types.gen.ts(70 hunks)packages/insight/src/configure.ts(1 hunks)packages/insight/tsconfig.base.json(1 hunks)packages/nebula/openapi-ts.config.ts(1 hunks)packages/nebula/package.json(1 hunks)packages/nebula/src/client/client.gen.ts(2 hunks)packages/nebula/src/client/client/client.ts(1 hunks)packages/nebula/src/client/client/index.ts(1 hunks)packages/nebula/src/client/client/types.ts(1 hunks)packages/nebula/src/client/client/utils.ts(1 hunks)packages/nebula/src/client/core/auth.ts(1 hunks)packages/nebula/src/client/core/bodySerializer.ts(1 hunks)packages/nebula/src/client/core/params.ts(1 hunks)packages/nebula/src/client/core/pathSerializer.ts(1 hunks)packages/nebula/src/client/core/types.ts(1 hunks)packages/nebula/src/client/sdk.gen.ts(1 hunks)packages/nebula/src/client/types.gen.ts(3 hunks)packages/nebula/src/configure.ts(1 hunks)packages/nebula/tsconfig.base.json(1 hunks)packages/thirdweb/.size-limit.json(1 hunks)packages/thirdweb/src/transaction/transaction-store.ts(1 hunks)
✅ Files skipped from review due to trivial changes (3)
- packages/thirdweb/.size-limit.json
- packages/engine/src/client/core/auth.ts
- packages/nebula/src/client/core/auth.ts
🚧 Files skipped from review as they are similar to previous changes (36)
- packages/engine/src/client/client.gen.ts
- packages/engine/src/configure.ts
- packages/nebula/src/configure.ts
- packages/insight/src/configure.ts
- packages/insight/src/client/client.gen.ts
- packages/nebula/src/client/sdk.gen.ts
- packages/engine/package.json
- packages/nebula/package.json
- packages/insight/package.json
- packages/insight/tsconfig.base.json
- packages/nebula/openapi-ts.config.ts
- packages/nebula/src/client/client.gen.ts
- packages/thirdweb/src/transaction/transaction-store.ts
- .changeset/little-items-allow.md
- packages/engine/tsconfig.base.json
- packages/nebula/tsconfig.base.json
- packages/insight/src/client/core/auth.ts
- packages/nebula/src/client/client/index.ts
- packages/insight/src/client/core/types.ts
- packages/engine/src/client/types.gen.ts
- packages/engine/src/client/sdk.gen.ts
- packages/nebula/src/client/types.gen.ts
- packages/nebula/src/client/core/types.ts
- packages/insight/src/client/client/index.ts
- packages/nebula/src/client/core/params.ts
- packages/engine/src/client/client/index.ts
- packages/engine/src/client/core/params.ts
- packages/insight/src/client/core/params.ts
- packages/nebula/src/client/core/bodySerializer.ts
- packages/insight/src/client/core/bodySerializer.ts
- packages/engine/src/client/core/bodySerializer.ts
- packages/insight/src/client/core/pathSerializer.ts
- packages/nebula/src/client/core/pathSerializer.ts
- packages/nebula/src/client/client/utils.ts
- packages/insight/src/client/types.gen.ts
- packages/insight/src/client/sdk.gen.ts
🧰 Additional context used
📓 Path-based instructions (1)
`**/*.@(ts|tsx)`: Accept a typed 'props' object and export a named function (e.g...
**/*.@(ts|tsx): Accept a typed 'props' object and export a named function (e.g., export function MyComponent()).
Combine class names via 'cn', expose 'className' prop if useful.
Reuse core UI primitives; avoid re-implementing buttons, cards, modals.
Local state or effects live inside; data fetching happens in hooks.
Merge class names with 'cn' from '@/lib/utils' to keep conditional logic readable.
Stick to design-tokens: background ('bg-card'), borders ('border-border'), muted text ('text-muted-foreground') etc.
Use the 'container' class with a 'max-w-7xl' cap for page width consistency.
Spacing utilities ('px-', 'py-', 'gap-*') are preferred over custom margins.
Responsive helpers follow mobile-first ('max-sm', 'md', 'lg', 'xl').
Never hard-code colors – always go through Tailwind variables.
Tailwind CSS is the styling system – avoid inline styles or CSS modules.
Prefix files with 'import "server-only";' so they never end up in the client bundle (for server-only code).
📄 Source: CodeRabbit Inference Engine (.cursor/rules/dashboard.mdc)
List of files the instruction was applied to:
packages/engine/src/client/core/types.tspackages/insight/src/client/client/client.tspackages/engine/src/client/client/client.tspackages/nebula/src/client/client/client.tspackages/engine/src/client/client/utils.tspackages/engine/src/client/core/pathSerializer.tspackages/insight/src/client/client/utils.tspackages/insight/src/client/client/types.tspackages/engine/src/client/client/types.tspackages/nebula/src/client/client/types.ts
🧬 Code Graph Analysis (2)
packages/engine/src/client/core/types.ts (2)
packages/engine/src/client/core/auth.ts (2)
Auth(3-18)AuthToken(1-1)packages/engine/src/client/core/bodySerializer.ts (3)
BodySerializer(9-9)QuerySerializer(7-7)QuerySerializerOptions(11-15)
packages/engine/src/client/client/utils.ts (5)
packages/engine/src/client/core/pathSerializer.ts (5)
ArrayStyle(18-18)ArraySeparatorStyle(19-19)serializeArrayParam(67-109)serializeObjectParam(129-179)serializePrimitiveParam(111-127)packages/engine/src/client/client/index.ts (9)
QuerySerializerOptions(2-2)Config(13-13)RequestOptions(17-17)Client(11-11)mergeHeaders(22-22)Options(15-15)createConfig(22-22)ClientOptions(12-12)jsonBodySerializer(5-5)packages/engine/src/client/core/bodySerializer.ts (3)
QuerySerializerOptions(11-15)QuerySerializer(7-7)jsonBodySerializer(58-63)packages/engine/src/client/client/types.ts (5)
Config(10-59)RequestOptions(61-82)Client(165-167)Options(191-199)ClientOptions(129-133)packages/engine/src/client/core/auth.ts (1)
getAuthToken(20-40)
⏰ Context from checks skipped due to timeout of 90000ms (8)
- GitHub Check: Lint Packages
- GitHub Check: Size
- GitHub Check: Unit Tests
- GitHub Check: E2E Tests (pnpm, esbuild)
- GitHub Check: E2E Tests (pnpm, webpack)
- GitHub Check: E2E Tests (pnpm, vite)
- GitHub Check: Build Packages
- GitHub Check: Analyze (javascript)
🔇 Additional comments (5)
packages/engine/src/client/core/types.ts (1)
1-98: Well-structured type definitions.The interface design follows TypeScript best practices with appropriate use of generics, comprehensive configuration options, and clear documentation. The separation of concerns between Client and Config interfaces is excellent.
packages/engine/src/client/client/utils.ts (1)
1-418: Well-structured HTTP client utilities implementation.The utility module provides comprehensive functionality for URL construction, serialization, authentication, and interceptor management. The implementation follows OpenAPI standards and handles edge cases appropriately.
packages/insight/src/client/client/utils.ts (1)
205-218: Good simplification of switch statement.The switch statement correctly handles the default case for headers, which is cleaner than the engine version.
packages/insight/src/client/client/types.ts (1)
1-223: Comprehensive and well-structured type definitions.The type system provides excellent flexibility for response styles, error handling, and request configuration. The conditional types appropriately handle different client behavior modes.
packages/engine/src/client/client/types.ts (1)
1-83: Well-designed client type definitions.The configuration, request options, and utility types are comprehensive and well-documented, providing excellent type safety for the client implementation.
Also applies to: 128-223
| } | ||
| } | ||
|
|
||
| finalError = finalError || ({} as string); |
There was a problem hiding this comment.
Same type casting issue as other client implementations.
This implementation has the identical type safety problem as the engine and insight clients - incorrectly casting an empty object as a string for error fallback.
Apply the same fix as suggested for the other client implementations:
- finalError = finalError || ({} as string);
+ finalError = finalError || "";📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| finalError = finalError || ({} as string); | |
| - finalError = finalError || ({} as string); | |
| + finalError = finalError || ""; |
🤖 Prompt for AI Agents
In packages/nebula/src/client/client/client.ts at line 158, the code incorrectly
casts an empty object as a string for the error fallback, causing type safety
issues. Replace the cast with a proper fallback value of an empty string or a
string message instead of using an empty object cast to string. This aligns with
the fix applied in other client implementations to ensure type safety.
| Object.entries(value).forEach(([key, v]) => { | ||
| values = [ | ||
| ...values, | ||
| key, | ||
| allowReserved ? (v as string) : encodeURIComponent(v as string), | ||
| ]; | ||
| }); |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Add type safety for object value serialization.
The code uses type assertions without validation, which could cause runtime errors if object values aren't strings.
Consider adding type validation:
values = [
...values,
key,
- allowReserved ? (v as string) : encodeURIComponent(v as string),
+ allowReserved ? String(v) : encodeURIComponent(String(v)),
];📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| Object.entries(value).forEach(([key, v]) => { | |
| values = [ | |
| ...values, | |
| key, | |
| allowReserved ? (v as string) : encodeURIComponent(v as string), | |
| ]; | |
| }); | |
| Object.entries(value).forEach(([key, v]) => { | |
| values = [ | |
| ...values, | |
| key, | |
| allowReserved ? String(v) : encodeURIComponent(String(v)), | |
| ]; | |
| }); |
🤖 Prompt for AI Agents
In packages/engine/src/client/core/pathSerializer.ts around lines 146 to 152,
the code assumes object values are strings using type assertions without
validation, risking runtime errors. Add a type check to verify each value is a
string before processing; if not, handle the case appropriately (e.g., skip,
convert, or throw an error) to ensure type safety during serialization.
| }) => { | ||
| if (!explode) { | ||
| const joinedValues = ( | ||
| allowReserved ? value : value.map((v) => encodeURIComponent(v as string)) |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Add type validation for array serialization.
The code uses type assertion v as string without validating that the value is actually a string. This could cause runtime errors if the array contains non-string values.
Consider adding type validation:
- ).join(separatorArrayNoExplode(style));
+ ).map(v => typeof v === 'string' ? v : String(v))
+ .join(separatorArrayNoExplode(style));Committable suggestion skipped: line range outside the PR's diff.
🤖 Prompt for AI Agents
In packages/engine/src/client/core/pathSerializer.ts at line 78, the code uses a
type assertion to treat each element as a string without validating the type,
which may cause runtime errors if non-string values are present. Modify the map
function to first check if each element is a string before encoding; if an
element is not a string, handle it appropriately, such as by converting it to a
string or skipping it, to ensure safe serialization.
| export type RequestResult< | ||
| TData = unknown, | ||
| TError = unknown, | ||
| ThrowOnError extends boolean = boolean, | ||
| TResponseStyle extends ResponseStyle = "fields", | ||
| > = ThrowOnError extends true | ||
| ? Promise< | ||
| TResponseStyle extends "data" | ||
| ? TData extends Record<string, unknown> | ||
| ? TData[keyof TData] | ||
| : TData | ||
| : { | ||
| data: TData extends Record<string, unknown> | ||
| ? TData[keyof TData] | ||
| : TData; | ||
| request: Request; | ||
| response: Response; | ||
| } | ||
| > | ||
| : Promise< | ||
| TResponseStyle extends "data" | ||
| ? | ||
| | (TData extends Record<string, unknown> | ||
| ? TData[keyof TData] | ||
| : TData) | ||
| | undefined | ||
| : ( | ||
| | { | ||
| data: TData extends Record<string, unknown> | ||
| ? TData[keyof TData] | ||
| : TData; | ||
| error: undefined; | ||
| } | ||
| | { | ||
| data: undefined; | ||
| error: TError extends Record<string, unknown> | ||
| ? TError[keyof TError] | ||
| : TError; | ||
| } | ||
| ) & { | ||
| request: Request; | ||
| response: Response; | ||
| } | ||
| >; |
There was a problem hiding this comment.
Identical data extraction issue as engine package.
The RequestResult type uses the same TData[keyof TData] pattern that can be unpredictable for multi-property objects, identical to the issue in the engine package.
Consider applying the same fix suggested for the engine package to ensure consistent behavior across packages.
🤖 Prompt for AI Agents
In packages/nebula/src/client/client/types.ts between lines 84 and 127, the
RequestResult type extracts data using TData[keyof TData], which can cause
unpredictable results for objects with multiple properties. To fix this, revise
the type to avoid indexing TData by keyof TData and instead return TData
directly or apply a safer extraction method consistent with the fix used in the
engine package, ensuring consistent and predictable data typing across packages.
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (3)
packages/nebula/src/client/client/utils.ts (3)
86-88: Fix label style encoding to exclude the prefix from URL encoding.The dot prefix for label style should not be URL-encoded.
148-187: Fix return type inconsistency in getParseAs function.The function returns
undefinedon line 160 and 186, but the return type doesn't include it.
338-344: Fix potential bug with interceptor index 0.The check
this._fns[id]will fail whenidis 0 and could return incorrect results.
🧹 Nitpick comments (10)
packages/nebula/src/client/client/utils.ts (10)
47-51: Add type safety for path parameter validation.The function doesn't validate that the path parameter values are serializable types before processing them.
const value = path[name]; if (value === undefined || value === null) { continue; } + + // Validate that the value is a serializable type + if (typeof value !== 'string' && typeof value !== 'number' && typeof value !== 'boolean' && !Array.isArray(value) && typeof value !== 'object') { + throw new Error(`Invalid path parameter type for "${name}": ${typeof value}`); + }
78-82: Add type validation for primitive parameter casting.The code casts
valuetostringwithout validation, which could lead to runtime errors.url = url.replace( match, `;${serializePrimitiveParam({ name, - value: value as string, + value: String(value), })}`, );
86-89: Improve type safety for value casting.The casting to
stringshould be safer by usingString()conversion.const replaceValue = encodeURIComponent( - style === "label" ? `.${value as string}` : (value as string), + String(value) ); - url = url.replace(match, replaceValue); + url = url.replace(match, style === "label" ? `.${replaceValue}` : replaceValue);
131-137: Add type validation for primitive value casting.Similar to other cases, the casting to
stringshould be safer.const serializedPrimitive = serializePrimitiveParam({ allowReserved, name, - value: value as string, + value: String(value), });
206-211: Validate query object mutation safety.The function mutates the
options.queryobject without ensuring it's safe to modify.case "query": if (!options.query) { options.query = {}; + } else if (typeof options.query !== 'object') { + throw new Error('Query parameter must be an object'); } options.query[name] = token; break;
292-295: Add type safety for array value iteration.The casting of array values to
stringcould be unsafe if the array contains non-string values.} else if (Array.isArray(value)) { for (const v of value) { - mergedHeaders.append(key, v as string); + mergedHeaders.append(key, String(v)); }
298-301: Improve type safety for header value casting.The casting to
stringshould be safer and more explicit about object handling.mergedHeaders.set( key, - typeof value === "object" ? JSON.stringify(value) : (value as string), + typeof value === "object" ? JSON.stringify(value) : String(value), );
344-347: Simplify exists method logic.The
existsmethod can be simplified by using the result fromgetInterceptorIndexdirectly.exists(id: number | Interceptor) { const index = this.getInterceptorIndex(id); - return !!this._fns[index]; + return index !== -1 && this._fns[index] !== null; }
349-354: Add bounds checking for array access.The method should validate the index before accessing the array.
eject(id: number | Interceptor) { const index = this.getInterceptorIndex(id); - if (this._fns[index]) { + if (index !== -1 && this._fns[index]) { this._fns[index] = null; } }
356-364: Add bounds checking for array access.Similar to the
ejectmethod, this should validate the index.update(id: number | Interceptor, fn: Interceptor) { const index = this.getInterceptorIndex(id); - if (this._fns[index]) { + if (index !== -1 && this._fns[index]) { this._fns[index] = fn; return id; } else { return false; } }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
packages/nebula/src/client/client/client.ts(1 hunks)packages/nebula/src/client/client/index.ts(1 hunks)packages/nebula/src/client/client/types.ts(1 hunks)packages/nebula/src/client/client/utils.ts(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (3)
- packages/nebula/src/client/client/index.ts
- packages/nebula/src/client/client/client.ts
- packages/nebula/src/client/client/types.ts
🧰 Additional context used
📓 Path-based instructions (1)
`**/*.@(ts|tsx)`: Accept a typed 'props' object and export a named function (e.g...
**/*.@(ts|tsx): Accept a typed 'props' object and export a named function (e.g., export function MyComponent()).
Combine class names via 'cn', expose 'className' prop if useful.
Reuse core UI primitives; avoid re-implementing buttons, cards, modals.
Local state or effects live inside; data fetching happens in hooks.
Merge class names with 'cn' from '@/lib/utils' to keep conditional logic readable.
Stick to design-tokens: background ('bg-card'), borders ('border-border'), muted text ('text-muted-foreground') etc.
Use the 'container' class with a 'max-w-7xl' cap for page width consistency.
Spacing utilities ('px-', 'py-', 'gap-*') are preferred over custom margins.
Responsive helpers follow mobile-first ('max-sm', 'md', 'lg', 'xl').
Never hard-code colors – always go through Tailwind variables.
Tailwind CSS is the styling system – avoid inline styles or CSS modules.
Prefix files with 'import "server-only";' so they never end up in the client bundle (for server-only code).
📄 Source: CodeRabbit Inference Engine (.cursor/rules/dashboard.mdc)
List of files the instruction was applied to:
packages/nebula/src/client/client/utils.ts
⏰ Context from checks skipped due to timeout of 90000ms (6)
- GitHub Check: Analyze (javascript)
- GitHub Check: E2E Tests (pnpm, esbuild)
- GitHub Check: E2E Tests (pnpm, vite)
- GitHub Check: E2E Tests (pnpm, webpack)
- GitHub Check: Size
- GitHub Check: Lint Packages
This PR updates the version of the
@hey-api/openapi-tspackage to0.76.0in the@thirdweb-dev/engine,@thirdweb-dev/insightand@thirdweb-dev/nebulapackages. Also, it adds a check in thechain_idin thethirdwebpackage in case it gets returned as a string and not as a number.PR-Codex overview
This PR focuses on updating the
@hey-apidependencies, enhancing type definitions, and refining client configurations across multiple packages, includingthirdweb,engine, andinsight.Detailed summary
limitin.size-limit.jsonfrom65 kBto68 kB.@hey-api/openapi-tsversion to0.76.0inpackage.jsonfiles.clientfiles.createClientfunctions.types.gen.ts.Summary by CodeRabbit
New Features
Enhancements
Bug Fixes
chain_id,block_number, and transaction values across APIs.chainId.Chores