Importing StrKey from @stellar/stellar-sdk v16 eagerly loads ESM-only/networking deps; request base-only subpath export #1533

Summary

After upgrading/using @stellar/[email protected], importing a base-only symbol such as StrKey from the package root causes Jest/CommonJS test environments to load unrelated SDK modules and ESM-only transitive dependencies.

We only need Stellar address validation:

import { StrKey } from '@stellar/stellar-sdk';

StrKey.isValidEd25519PublicKey(address);

However, this root import appears to eagerly load additional SDK areas such as federation/webauth/rpc/networking dependencies. In our Jest setup this causes failures from ESM-only transitive dependencies under node_modules.

Environment

• @stellar/stellar-sdk: 16.0.1
• Node: 22.15.0
• Package manager: pnpm
• Test runner: Jest with ts-jest
• TypeScript target used by tests before workaround: es2015

Observed behavior

A root import of StrKey from @stellar/stellar-sdk works in Node/tsx:

var { StrKey } = await import("@stellar/stellar-sdk");

But in Jest, because the package root eagerly loads the SDK dependency graph, tests fail with errors like:

SyntaxError: Cannot use import statement outside a module

from ESM-only transitive dependencies, including packages such as:

@noble/hashes
@noble/ed25519
uint8array-extras
smol-toml
eventsource
axios

After allowlisting those packages for transform, we also hit a BigInt downlevel issue with @noble/ed25519 when ts-jest compiles with an es2015 target:

TypeError: Cannot convert a BigInt value to a number

This required changing the Jest/ts-jest spec target to es2020.

Expected behavior

Importing a base-only primitive such as StrKey should not require consumers to load unrelated networking/RPC/webauth/federation modules or their transitive dependencies.

Ideally, consumers should be able to import base-only APIs through a public subpath export, for example:

import { StrKey } from "@stellar/stellar-sdk/base";

or:

import { StrKey } from "@stellar/stellar-sdk/strkey";

Things tried

@stellar/stellar-base is no longer available in our install after v16:

await import("@stellar/stellar-base");

fails with:

Error [ERR_MODULE_NOT_FOUND]: Cannot find package '@stellar/stellar-base'

A deep SDK import is also not available because of package exports:

await import("@stellar/stellar-sdk/lib/strkey");

fails with:

Error [ERR_PACKAGE_PATH_NOT_EXPORTED]: Package subpath './lib/strkey' is not defined by "exports"

So the only supported import path appears to be:

import { StrKey } from "@stellar/stellar-sdk";

which loads much more than needed.

Current workaround

We worked around this by changing Jest config to transform specific ESM-only dependencies and by raising the ts-jest spec target to es2020, but this is a large workaround for a simple address-validation use case.

Request

Would you consider exposing a stable base-only subpath export for primitives like StrKey, Keypair, etc., or making the package root avoid eager-loading networking/RPC modules when only base symbols are imported?

This would make the v16 @stellar/stellar-base fold-in much easier for Jest/CommonJS/monorepo consumers.