[bryzettler]

Problem

@helium/onboarding@5.0.4 publishes build/*.d.ts files that start with:

/// <reference types="jito-ts/node_modules/@solana/web3.js" />

This affects 5 files: SolanaOnboarding, MobileHotspotOnboarding, WifiHttpClient, ConfigurationClient and __mocks__/AssertMock. The reference loads web3.js 1.77.4, which declares its types as an ambient declare module "@solana/web3.js". That hides the installed web3.js types in downstream apps. wallet-app has type-checked against 1.77.4 no matter which web3.js it installs.

Cause

onboarding's lockfile resolves @helium/data-credits-sdk 0.11.4. That version's lib/types/src/functions/mintDataCredits.d.ts already contains the reference, through @pythnetwork/solana-utils@0.4.5 → jito-ts@3.0.1 → @solana/web3.js ~1.77.3. tsc --explainFiles shows it is the only file that loads 1.77.4. Versions 0.11.4 to 0.11.11 have the reference. 0.11.12 and later are clean.

Change

• All HPL SDKs move together to the set published on 2026-09-10. The mixed set is not intentional, so the whole @helium/* HPL block moves:
  • @helium/spl-utils ^0.11.4 → ^0.13.3. 0.13.3 is the first version whose sendAndConfirmWithRetry and bulkSendRawTransactions read with maxSupportedTransactionVersion: 1.
  • @helium/data-credits-sdk ^0.11.4 → ^0.12.1
  • @helium/currency-utils ^0.11.4 → ^0.12.0
  • @helium/helium-entity-manager-sdk ^0.11.4 → ^0.11.19
  • @helium/hotspot-utils ^0.11.4 → ^0.11.19
• The lockfile now resolves one copy each of spl-utils (0.13.4) and helium-sub-daos-sdk (0.12.0).
• @solana/web3.js ^1.91.1 → ^1.99.0, because spl-utils 0.13 requires ^1.99.0. The lockfile is deduped to a single 1.99.0. Without this change, anchor and spl-utils each load their own Connection type and the build fails.
• currency-utils 0.12 removed cluster from getOraclePrice. The private helper getOraclePriceInCentsFromSolana no longer takes it. getUpdateMetaData keeps cluster in its public options type for compatibility, but no longer uses it.
• The lockfile also picks up transitive refreshes. It was already out of date with package.json, so yarn install --frozen-lockfile failed before this change.

jito-ts and its private web3.js 1.77.4 stay in the tree through currency-utils → @pythnetwork/pyth-solana-receiver. No published HPL .d.ts references it, and nothing in onboarding's build does.

Verification

• yarn build in packages/onboarding passes.
• grep -rl 'reference types=".*node_modules' build returns nothing. It returned 5 files before this change. Only node and bn.js type references remain.
• grep -rl 'reference types=".*node_modules' node_modules/@helium/*/lib/types returns nothing. This checks the latest versions in each caret range, not only a hand-pinned version.
• A clean yarn install --frozen-lockfile in a scratch copy passes. It installs web3.js only at 1.99.0, plus 1.77.4 nested under jito-ts.
• The installed spl-utils has maxSupportedTransactionVersion: 1 at all its call sites.
• A clean rebuild on the old lockfile still emits the reference, so republishing without this change does not fix it.
• jest packages/onboarding: 22 of 22 tests pass.

Version 5.0.5

This PR also bumps every package to 5.0.5, following the pattern of #384 (lerna fixed mode):

1. Update yarn.lock files for release 5.0.5: a plain yarn install in each package moves the @helium/* lock entries from ^5.0.3 to ^5.0.4.
2. v5.0.5: lerna version 5.0.5 --no-push --no-git-tag-version. Its preversion build passed for all 10 packages, and the rebuilt onboarding .d.ts files still carry no nested references.

After merge, tag and publish 5.0.5 so consumers pick up the fixed typings.

After 5.0.5 is published, remove the cast in BrowserWebViewScreen.tsx from helium/wallet-app#1055. It exists only because of this bug.

[madninja]

The diagnosis is solid and the verification is the right kind: tsc --explainFiles to find the single file that pulls 1.77.4, a grep over build that returned five files before and none after, and a clean rebuild on the old lockfile to prove republishing alone would not have fixed it. The version range that carries the reference is stated precisely. No argument with the change as far as it goes.

One thing I would fold in, and one question.

Bump @helium/spl-utils too, to ^0.13.3 or later. @helium/onboarding calls sendAndConfirmWithRetry and bulkSendRawTransactions from spl-utils, and both contain maxSupportedTransactionVersion call sites. I checked the published tarballs: every 0.11.x and 0.13.0 through 0.13.2 ship those four sites at : 0, and 0.13.3 is the first with : 1 (0.13.4 is current). The dependency here is ^0.11.4, so the caret can never reach it. Mainnet has been producing v1 transactions since 2026-09-15, so onboarding is structurally pinned to the pre-v1 read path. It is latent rather than breaking today, since those functions read back transactions the caller just sent and web3.js 1.x cannot build a v1, but it is the same class of problem as helium/wallet-app#1055, and this PR is the natural place to close it while the ranges are already being moved.

Why only @helium/data-credits-sdk? The other HPL SDKs stay at ^0.11.4 while that one moves to ^0.11.12, so onboarding now spans two generations of a set that HPL publishes in lockstep. That is fine if the only goal is dropping the leaked reference, and the grep proves it worked. It is worth saying explicitly in the PR body whether the mixed set is intentional and bounded, or whether the whole @helium/* block should move together, because the next person to touch this will otherwise have to re-derive the answer. Related: @helium/currency-utils, helium-entity-manager-sdk, hotspot-utils and spl-utils all sit at ^0.11.4 against published 0.12/0.13 lines.

Minor: the PR body says 0.11.12 and later are clean for data-credits-sdk. Pinning the lockfile at exactly 0.11.12 while the range says ^0.11.12 means a fresh resolve can take a later 0.11.x, which is intended, but worth one line confirming the grep was run against the range rather than only the pinned version.

Once 5.0.5 is published, helium/wallet-app#1055 has a cast in BrowserWebViewScreen.tsx that exists only because of this bug and should come out.

[bryzettler]

@madninja Thanks. I made the changes in d66209f.

spl-utils: It is now ^0.13.3, and the lockfile resolves 0.13.4. All call sites in the installed package use maxSupportedTransactionVersion: 1.

Why only data-credits-sdk: It was not intentional. The whole HPL block now moves to the set published on 2026-09-10: data-credits-sdk ^0.12.1, currency-utils ^0.12.0, helium-entity-manager-sdk and hotspot-utils ^0.11.19, and spl-utils ^0.13.3. Each one depends on spl-utils ^0.13. The lockfile now has one copy each of spl-utils and helium-sub-daos-sdk.

This bump needed two more changes:

• @solana/web3.js moves to ^1.99.0, because spl-utils 0.13 requires it. The lockfile is deduped to one 1.99.0. Otherwise anchor and spl-utils load different Connection types, and the build fails.
• currency-utils 0.12 removed cluster from getOraclePrice. The private helper no longer passes it. getUpdateMetaData still accepts cluster, so callers do not break, but it does not use the value.

Range vs. pin: I ran the grep against node_modules/@helium/*/lib/types at the latest version each caret range resolves to. No file has a nested node_modules reference. jito-ts and its web3.js 1.77.4 are still in the tree through currency-utils → pyth-solana-receiver, but no emitted .d.ts references them.

The build passes, a clean --frozen-lockfile install passes, and jest passes 22 of 22. The PR body is updated, and it includes the follow-up for the wallet-app#1055 cast.