You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
CLI v27.0.0 ships Protocol 27 support, but the TypeScript bindings template still pins @stellar/stellar-sdk at ^14.5.0 (template). main is the same.
SDK v14 is the Protocol 23 line. Protocol 27 support landed in SDK v16 (16.0.1 is latest, published 2026-06-18). So stellar contract bindings typescript on the current CLI generates clients that cannot use P27 features, including the new AddressV2 auth entries that v27.0.0's own release notes call out. #2613 updated the Rust dependencies to Protocol 27 but did not touch this template.
The template also predates the v15 Class XDR rewrite, so every generated project starts two majors behind with a breaking migration ahead of it.
Impact
Template pins compound into ecosystem-wide version lag, because every generated project inherits them and lockfiles freeze them. From npm per-version download data (week of 2026-07-09, 528k total weekly downloads):
13.3.0 alone is 21.4% of all SDK downloads, matching the v22-era template pin of ^13.x.
14.1.1 is 16.1%, matching the v23-era pin of ^14.1.1.
14.6.1 (what ^14.5.0 resolves to today) is 5.8% and growing.
The latest major (v16) is at 9.7%.
Historic template pins line up with roughly a third of all SDK downloads. The bindings bump was done routinely before (#2373 in v25.2.0 updated "to the latest JS SDK version", also #2027, #1606), but the template has now missed two SDK majors, including the P27 release.
Ask
Update cmd/crates/soroban-spec-typescript/src/project_template/package.json to "@stellar/stellar-sdk": "^16.0.1", including any template code changes needed for the v15+ API (the Class XDR rewrite changed the XDR layer, so this is more than a version string), and ship it in a v27.x patch since the protocol mismatch affects the current release.
Add the template pin to the release checklist so it tracks SDK majors going forward.
Problem
CLI v27.0.0 ships Protocol 27 support, but the TypeScript bindings template still pins
@stellar/stellar-sdkat^14.5.0(template).mainis the same.SDK v14 is the Protocol 23 line. Protocol 27 support landed in SDK v16 (16.0.1 is
latest, published 2026-06-18). Sostellar contract bindings typescripton the current CLI generates clients that cannot use P27 features, including the new AddressV2 auth entries that v27.0.0's own release notes call out. #2613 updated the Rust dependencies to Protocol 27 but did not touch this template.The template also predates the v15 Class XDR rewrite, so every generated project starts two majors behind with a breaking migration ahead of it.
Impact
Template pins compound into ecosystem-wide version lag, because every generated project inherits them and lockfiles freeze them. From npm per-version download data (week of 2026-07-09, 528k total weekly downloads):
^13.x.^14.1.1.^14.5.0resolves to today) is 5.8% and growing.Historic template pins line up with roughly a third of all SDK downloads. The bindings bump was done routinely before (#2373 in v25.2.0 updated "to the latest JS SDK version", also #2027, #1606), but the template has now missed two SDK majors, including the P27 release.
Ask
cmd/crates/soroban-spec-typescript/src/project_template/package.jsonto"@stellar/stellar-sdk": "^16.0.1", including any template code changes needed for the v15+ API (the Class XDR rewrite changed the XDR layer, so this is more than a version string), and ship it in a v27.x patch since the protocol mismatch affects the current release.--js-stellar-sdk-versionoption tosoroban contract bindings typescript#1327 proposes a--js-stellar-sdk-versionflag. That would let users opt into newer SDKs between CLI releases and is a good complement, but the default is what drives ecosystem-wide adoption.