feat(hl-react): update hyperliquid api coverage

[vipineth]

No description provided.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
hypeterminal-main	Error		Jun 19, 2026 10:25am

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
hypeterminal-website	Ignored	Preview	Jun 19, 2026 10:25am

[claude]

Code Review

Overview

This PR expands hl-react to cover newer @nktkas/hyperliquid SDK methods (≥ 0.32.2): eight new EIP-712 / user-signed actions are added to the USER_SIGNED_METHODS registry, five previously-internal hooks are exposed as named package entry points, the peer-dep version range is tightened, and the README is updated with a coverage table, a HIP-4 status note, and updated import examples.

The changes are tightly scoped and well-structured. A few things are worth checking before merge.

---

Potential Bugs

userOutcome is missing from USER_SIGNED_METHODS

The README explicitly documents useExchange("userOutcome") as the HIP-4 exchange action, but userOutcome is not present in USER_SIGNED_METHODS in exchange.ts. If it requires EIP-712 user-wallet signing (like the other outcome-market actions), routing it through the agent wallet would silently produce wrong signatures at runtime. If it genuinely uses agent-signing (L1 action), that should be called out in the README rather than listed alongside EIP-712 methods.

setDisplayName is mentioned in the README but not added to the registry

The updated README body names setDisplayName as a new exchange action but it does not appear in USER_SIGNED_METHODS. Same question: agent-signed or user-signed? Either way the docs and registry should be consistent.

---

Code Quality

Sorting convention — the set uses case-sensitive ASCII ordering, so uppercase letters sort before their lowercase counterparts (cDeposit → cWithdraw → convertToMultiSigUser). This is consistent with how JavaScript's default Array.sort() behaves, but it is non-obvious when reading the list case-insensitively. Consider a comment or a sort-order lint rule if this causes repeated confusion in reviews.

Test coverage — the EXPECTED_USER_SIGNED array in hyperliquid-registries.test.ts is kept in sync, which is good. It would be worth also testing that the new methods are not accidentally absent from the set (i.e., the test asserts exact membership, not just a subset), so a future accidental deletion would fail the suite.

---

Public API Surface

Five hooks are newly exported as named entry points in package.json:

./hooks/useApiStatus
./hooks/useClients
./hooks/useExchange
./hooks/useTradingGuard
./hooks/useTransport

useClients, useApiStatus, useTradingGuard, and useTransport appear to be lower-level / infrastructure hooks. Exporting them locks in their signatures as part of the public contract. If they're intended to remain internal, they should stay unexported. If they're intentionally public, a changelog entry and a note in the README about stability would help consumers decide whether to depend on them.

---

Peer Dep Range

Changing from ^0.31.0 to >=0.32.2 <1 is reasonable given the minimum SDK version needed for these new methods. One thing to double-check: does any call-site in the monorepo (e.g. apps/terminal/package.json) pin a specific @nktkas/hyperliquid version that satisfies >=0.32.2? If apps/terminal still resolves an older version, the new hook calls will fail at runtime even though the package builds fine.

---

Summary

Area	Status
userOutcome routing	Needs clarification / likely a bug
setDisplayName routing	Needs clarification
Registry + test sync	Good
New package exports (internal hooks)	Intentional? Needs decision
Peer dep range	OK — verify app-level resolution
Documentation	Clear and well-written

Overall a clean PR — just address the two missing-methods questions and decide on the export-stability story before merging.

[claude]

Code Review

Overview

This PR expands the Hyperliquid API coverage in hl-react to align with @nktkas/hyperliquid v0.32.2. Changes include: adding 7 new methods to USER_SIGNED_METHODS, updating tests to match, bumping the peer dependency range, exposing additional fine-grained package entry points, and updating the README.

---

Positives

• Test coverage is in sync — hyperliquid-registries.test.ts is updated alongside the registry, keeping the invariant enforced.
• Focused diff — only the registry, its test, docs, and package exports change. No sprawl.
• Peer dep range — >=0.32.2 <1 is the right shape: pins the minimum to the version that introduced these methods, caps at the next major.

---

Issues

1. userOutcome and setDisplayName are missing from USER_SIGNED_METHODS

The README documents both as exchange actions available in v0.32.2:

useExchange("userOutcome") … setDisplayName

But neither appears in the USER_SIGNED_METHODS set in registries/exchange.ts. If they require EIP-712/user-wallet signing (which is likely for userOutcome, an outcome-market action), omitting them means useExchange will route them through the agent wallet and silently fail or sign with the wrong key.

Suggestion: Either add them to USER_SIGNED_METHODS (and to the test's EXPECTED_USER_SIGNED array), or add a comment explaining why agent-wallet signing is correct for them.

2. README import example is a breaking-change signal with no migration note

- import { subscriptionRegistry } from "@hypeterminal/hl-react/registries/subscription";
+ import { getAccumulateConfig } from "@hypeterminal/hl-react/registries/subscription";

If subscriptionRegistry was previously exported and is now removed/renamed, this is a breaking change for any consumer using that entry point. The PR title uses feat, not fix or a major-bump indicator. Consider:

• Adding a BREAKING CHANGE: note in the PR body / CHANGELOG if subscriptionRegistry is truly gone, or
• Re-exporting subscriptionRegistry as a deprecated alias if backward compat matters.

3. New package.json exports not verified in tests

Five new entry points are added:

"./hooks/useApiStatus"
"./hooks/useClients"
"./hooks/useExchange"
"./hooks/useTradingGuard"
"./hooks/useTransport"

If there's no build or resolution test that validates every export in exports resolves to a real file, a typo or missing file would only surface at consumer install time. Worth confirming these all exist and are included in the build output.

---

Minor / Nits

• The useClients.ts JSDoc update ("EIP-712/user-signed actions such as approvals, transfers, and withdrawals") is clearer than the original — good change.
• The README table and HIP-4 status paragraph are helpful additions for discoverability.
• Methods are alphabetically ordered in the test but not in exchange.ts (cDeposit, cWithdraw, convertToMultiSigUser, linkStakingUser appear in the middle of an otherwise-alpha list). Minor consistency issue.

---

Summary

The core change (registry + test) is correct. The two items worth resolving before merge:

1. Confirm userOutcome / setDisplayName routing — add to USER_SIGNED_METHODS if they need user-wallet signing, or document why they don't.
2. Clarify subscriptionRegistry → getAccumulateConfig rename — call it out as breaking if applicable.

[claude]

Code Review — feat(hl-react): update hyperliquid api coverage

Overview

This PR expands USER_SIGNED_METHODS in the exchange registry to cover 6 new SDK 0.32.2 methods, adds 5 new fine-grained subpath exports to package.json, updates the README to reflect current API coverage and the bumped peer-dep range, and backs everything with two new test files.

---

What's Good

• Test-first approach — Both new test files add genuine regression value. hl-react-exports.test.ts catches the "export points at a non-existent file" class of bug that's easy to miss. The hyperliquid-registries.test.ts additions are tight and cover the new routing expectations without over-specifying.
• Conservative skip in export test — if (target.includes("*")) continue; correctly avoids trying to resolve the glob pattern ./registries/*.
• Registry comment — The exchange.ts comment explaining why the default is trading (L1 action vs user-signed action) is one of the few cases where a comment is genuinely warranted per code-style.

---

Issues & Suggestions

1. PackageJson type in hl-react-exports.test.ts is too narrow

interface PackageJson {
  exports: Record<string, string>;
}

Node's exports field supports conditional exports ({ import: "...", require: "..." }), so the cast will silently mangle any entry that's an object. Right now every entry in this package is a string, so the test passes — but the type gives false confidence. Use unknown or the actual Node type if you want the assertion to mean something when the structure changes:

interface PackageJson {
  exports: Record<string, string | Record<string, string>>;
}

The downstream Object.entries would then need a typeof target === "string" guard before calling target.includes("*").

---

2. Redundant test — routes representative L1 methods to trading client

The test added just below the existing routes all other methods to trading client re-asserts a strict subset:

it("routes representative L1 methods to trading client", () => {
  const expectedL1Methods: ExchangeMethod[] = ["agentEnableDexAbstraction", "setDisplayName"];
  ...
});

routes all other methods to trading client already iterates over every non-user-signed method, so this is fully covered. The only value this provides is as living documentation of which methods are L1 examples. If that's the intent, a comment on the existing test is clearer; if not, remove it.

---

3. Comment in exchange.ts is slightly redundant on the third line

// All other ExchangeClient methods are L1 actions and intentionally use the
// agent trading client. Examples include setDisplayName and agentEnableDexAbstraction
// agent-side actions in the SDK, which call executeL1Action rather than       // <-- "agent-side actions" restates line 2
// executeUserSignedAction.

"Examples include setDisplayName and agentEnableDexAbstraction" is self-contained. "agent-side actions in the SDK" on the line below re-states it. Trim to:

// All other ExchangeClient methods are L1 actions routed to the trading client.
// They call executeL1Action in the SDK, not executeUserSignedAction.

---

4. Peer-dep range in README vs package.json says different things

package.json now has >=0.32.2 <1, which is a wide range that allows 0.33, 0.40, etc. The README note says:

this package documents and tests against the pinned workspace SDK version

If the workspace root pins to 0.32.2, that's fine for day-to-day development, but external consumers reading the README will think the package is tested against the full >=0.32.2 <1 range. Consider tightening the peer dep to ~0.32.2 (patch-level) until the package is actively tested against newer minors, or add a caveat that newer minors are untested.

---

5. Hardcoded relative path count in test

const PACKAGE_DIR = resolve(TEST_DIR, "../../../../../packages/hl-react");

Five ../ climbs are fragile — moving the test file one level breaks the path silently. Consider resolving from process.cwd() (workspace root when vitest runs) or using a findUp-style search for pnpm-workspace.yaml. Low priority since this is a stable test location, but worth noting.

---

Summary

Area	Status
Exchange registry correctness	✅ Correct — 6 new methods placed in the right set
New subpath exports	✅ All backed by existing source files; test validates this
Test coverage	✅ Good addition; one redundant case
README accuracy	✅ Fixes stale subscriptionRegistry → getAccumulateConfig example
Type safety in test	⚠️ PackageJson.exports type is too narrow
Comment verbosity	Minor nit
Peer-dep / README alignment	Minor concern on range vs tested set

Overall a clean, well-scoped PR. The PackageJson type narrowness is the only issue worth fixing before merge; the rest are nits.

[claude]

test comment - please ignore

[claude]

PR Review: feat(hl-react): update hyperliquid api coverage

Overview: This PR expands the hl-react package to cover newer Hyperliquid SDK 0.32.2 methods — adding 7 user-signed exchange actions to the registry, exposing 5 previously-internal hooks as named subpath exports, and adding a new test file that validates export-to-source-file integrity. Documentation is thorough and accurate.

---

What looks good:

• Registry change in exchange.ts is a clean, minimal diff — just add entries to the existing Set, no structural changes needed.
• The new hl-react-exports.test.ts is a solid defensive test: walking every export target and asserting the file exists catches stale entries automatically.
• Peer-dep rationale (>=0.32.2 <1 over the old ^0.31.0) is clearly explained in the README and is a reasonable trade-off for install compatibility.
• The corrected import example (getAccumulateConfig replacing the old subscriptionRegistry) is a good catch.

---

Issues / suggestions:

1. findWorkspaceRoot used before its declaration (readability)

Function declarations are hoisted so this works at runtime, but it breaks the top-to-bottom reading flow of the module. Move the helper above the const assignments at lines 15-19 of hl-react-exports.test.ts.

---

2. Second test only covers the 5 newly-added exports

useInfo and useSubscription existed before this PR. If either were accidentally removed from package.json, the 'exposes direct hook subpaths' test would still pass because it only asserts on the 5 new entries. Either add the pre-existing exports to the toMatchObject snapshot, or rename the test to clarify scope (e.g. 'exposes newly-added hook subpaths').

---

3. Two-line comment where one would do (code-style rule)

The project style guide allows a comment only when the WHY is non-obvious. The SDK call-path distinction (executeL1Action vs executeUserSignedAction) qualifies — but two lines is one too many. Collapse to a single line:

// Routes to trading client via SDK executeL1Action, not executeUserSignedAction.

---

4. Peer dependency range is intentionally broad — confirm no runtime availability gaps

=0.32.2 <1 lets consumers install any future 0.x minor without a workspace-pin bump. The README documents this clearly. Just confirm no production code path relies on a method that appeared only after 0.32.2 without a runtime availability check — otherwise a consumer on an older 0.x minor could get a silent failure.

---

Summary:

The core change (registry + exports + docs) is correct and well-tested. Two actionable asks before merge:

1. Move findWorkspaceRoot above the const block.
2. Extend the 'exposes direct hook subpaths' snapshot to include pre-existing exports (or rename to scope it explicitly).

The comment trimming and peer-dep check are minor. Overall a clean, well-scoped PR.

[claude]

PR Review: feat(hl-react): update hyperliquid api coverage

Overview: This PR expands the hl-react package to cover newer Hyperliquid SDK 0.32.2 methods — adding 7 user-signed exchange actions to the registry, exposing 5 previously-internal hooks as named subpath exports, and adding a new test file that validates export-to-source-file integrity. Documentation is thorough and accurate.

---

What looks good

• Registry change in exchange.ts is a clean, minimal diff — just add entries to the existing Set, no structural changes needed.
• The new hl-react-exports.test.ts is a solid defensive test: walking every export target and asserting the file exists catches stale entries automatically.
• Peer-dep rationale (>=0.32.2 <1 over the old ^0.31.0) is clearly explained in the README and is a reasonable trade-off for install compatibility.
• The corrected import example (getAccumulateConfig replacing the old subscriptionRegistry) is a good catch.

---

Issues / suggestions

1. findWorkspaceRoot used before its declaration (readability)

Function declarations are hoisted so this works at runtime, but it breaks the top-to-bottom reading flow of the module. Move the helper above the const assignments at lines 15-19 of hl-react-exports.test.ts.

---

2. Second test only covers the 5 newly-added exports

useInfo and useSubscription existed before this PR. If either were accidentally removed from package.json, the "exposes direct hook subpaths" test would still pass because it only asserts on the 5 new entries. Either add the pre-existing exports to the toMatchObject snapshot, or rename the test to clarify scope (e.g. "exposes newly-added hook subpaths").

---

3. Two-line comment where one would do (code-style rule)

The project style guide allows a comment only when the WHY is non-obvious. The SDK call-path distinction (executeL1Action vs executeUserSignedAction) qualifies — but two lines is one too many. Collapse to a single line:

// Routes to trading client via SDK executeL1Action, not executeUserSignedAction.

---

4. Peer dependency range is intentionally broad — confirm no runtime availability gaps

>=0.32.2 <1 lets consumers install any future 0.x minor without a workspace-pin bump. The README documents this clearly. Just confirm no production code path relies on a method that appeared only after 0.32.2 without a runtime availability check — otherwise a consumer on an older 0.x minor could get a silent failure.

---

Summary

The core change (registry + exports + docs) is correct and well-tested. Two actionable asks before merge:

1. Move findWorkspaceRoot above the const block.
2. Extend the "exposes direct hook subpaths" snapshot to include pre-existing exports (or rename to scope it explicitly).

The comment trimming and peer-dep check are minor. Overall a clean, well-scoped PR.