packages/sdk's own tsc build (pnpm --filter @azable/sdk build) has 280 pre-existing type errors when compiling its source directly — separate from and much larger than the ~40 errors apps/web's build sees (#2), because apps/web only type-checks against the SDK's already-built dist/, never its source.
The build still succeeds and produces a complete dist/ (both ESM and CJS) despite this — tsc emits JS on type errors since noEmitOnError isn't set, and the build script is ;-chained so a non-zero tsc exit doesn't abort the pipeline. So this isn't currently blocking anything, but it's real debt. Two distinct root causes:
- Missing
.js extensions on relative imports — the large majority of the 280 errors are TS2835/TS2834: tsconfig.json sets moduleResolution: "node16", which requires explicit .js extensions on every relative import (import "./foo.js", not import "./foo"), and almost none of the ~40 source files in src/ do this.
- API drift against the installed
@stellar/stellar-sdk version — SorobanRpc renamed to Soroban, @stellar/stellar-sdk/contract and /rpc subpath resolution failing under node16, AssembledTransaction<T> now requiring a type argument, Client.txFromJSON renamed to fromJSON, SorobanResources.readBytes removed, and others.
There are also a few real duplicate-identifier bugs independent of the SDK version drift (e.g. allowHttp declared twice in deployer/types.ts and utils/GasEstimator.ts) worth fixing regardless.
To do: run pnpm --filter @azable/sdk exec tsc -p tsconfig.json --noEmit locally to get the current list, fix the .js-extension imports first (mechanical, likely scriptable), then work through the API-drift errors against the pinned @stellar/stellar-sdk version.
packages/sdk's owntscbuild (pnpm --filter @azable/sdk build) has 280 pre-existing type errors when compiling its source directly — separate from and much larger than the ~40 errors apps/web's build sees (#2), because apps/web only type-checks against the SDK's already-builtdist/, never its source.The build still succeeds and produces a complete
dist/(both ESM and CJS) despite this —tscemits JS on type errors sincenoEmitOnErrorisn't set, and the build script is;-chained so a non-zerotscexit doesn't abort the pipeline. So this isn't currently blocking anything, but it's real debt. Two distinct root causes:.jsextensions on relative imports — the large majority of the 280 errors areTS2835/TS2834:tsconfig.jsonsetsmoduleResolution: "node16", which requires explicit.jsextensions on every relative import (import "./foo.js", notimport "./foo"), and almost none of the ~40 source files insrc/do this.@stellar/stellar-sdkversion —SorobanRpcrenamed toSoroban,@stellar/stellar-sdk/contractand/rpcsubpath resolution failing undernode16,AssembledTransaction<T>now requiring a type argument,Client.txFromJSONrenamed tofromJSON,SorobanResources.readBytesremoved, and others.There are also a few real duplicate-identifier bugs independent of the SDK version drift (e.g.
allowHttpdeclared twice indeployer/types.tsandutils/GasEstimator.ts) worth fixing regardless.To do: run
pnpm --filter @azable/sdk exec tsc -p tsconfig.json --noEmitlocally to get the current list, fix the.js-extension imports first (mechanical, likely scriptable), then work through the API-drift errors against the pinned@stellar/stellar-sdkversion.