Feat: Replace Standalone with Local in TS Boilerplate

[zachfedor]

What

Generated TS bindings create an object with keys for each network. This will replace the legacy "standalone" key with the new "local" key. Network passphrases are not changed, just the key to reference them.

Why

This will simplify configuration needed for Scaffold Stellar projects. A single environment variable can be set to match one of the keys on this network object and spread out defaults to instantiate the contract's RPC client with the RPC URL and network passphrase, rather than having each individual piece defined as an environment variable.

This shouldn't be a breaking change as we'll still allow these individual environment variables to overwrite the defaults for a given a network.

Known limitations

[N/A]

[leighmcculloch]

Using the 'local' term to match quickstart is preferred, good call.

I would think this would be a breaking change because the generated networks object has a value for its standalone field today, but that will be undefined after this is merged.

For example, looking at the tests:

import {
  Client,
  networks,
  contract as ContractClient,
} from "test-custom-types";

//...

const contract = new Client({
  ...networks.standalone,
  ...networks.local,
  rpcUrl,
  allowHttp: true,
  publicKey: root.keypair.publicKey(),
  ...signer,
});

I note in the description you say this is not a breaking change. Why is that?

Is there a way to make this non-breaking, such as by having networks contain both standalone and local map to the same value?

[zachfedor]

Regardless of what the key is called, we still destructure the same values as before. What was ...networks.standalone is now ...networks.local, but it all results in the same generated code:

// src/contracts/some-contract.ts
export default new Client.Client({
  networkPassphrase: 'Standalone Network ; February 2017',
  contractId: 'C...',
  rpcUrl,
  allowHttp: true,
  publicKey: undefined,
});

I'm not seeing anywhere else where we actually use this networks object.

We could add both keys containing the same values, but would that be confusing?

[leighmcculloch]

I'm not seeing anywhere else where we actually use this networks object.

Looking at the tests the networks object appears to be exported.

The tests demonstrate it being used like below, see line 5 where the exported object is imported, and line 12 where the object is used:

stellar-cli/cmd/crates/soroban-spec-typescript/ts-tests/src/test-custom-types.ts

Lines 3 to 17 in 4dd685d

	import {
	Client,
	networks,
	contract as ContractClient,
	} from "test-custom-types";
	const publicKey = root.keypair.publicKey();
	const contract = new Client({
	...networks.local,
	rpcUrl,
	allowHttp: true,
	publicKey: root.keypair.publicKey(),
	...signer,
	});

[Copilot]

Pull request overview

This PR updates the TypeScript bindings boilerplate to use the local network key (instead of the legacy standalone) when the network passphrase corresponds to the local/standalone dev network, and updates the TypeScript test suite to reference networks.local.

Changes:

• Map the standalone/local dev network passphrase to the "local" key in the generated networks object.
• Update TS tests to use ...networks.local instead of ...networks.standalone.
• Reformat and extend test-custom-types.ts (note: includes new tests beyond the network-key rename).

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

File	Description
cmd/crates/soroban-spec-typescript/src/boilerplate.rs	Changes the generated TS networks object key from standalone to local for the local dev passphrase.
cmd/crates/soroban-spec-typescript/ts-tests/src/test-xlm-lib-from-sac.ts	Updates usage to spread networks.local.
cmd/crates/soroban-spec-typescript/ts-tests/src/test-deserialized-transaction.ts	Updates usage to spread networks.local.
cmd/crates/soroban-spec-typescript/ts-tests/src/test-custom-types.ts	Updates usage to networks.local and includes additional test changes/additions.

Comments suppressed due to low confidence (2)

cmd/crates/soroban-spec-typescript/ts-tests/src/test-custom-types.ts:225

• The TS tests call contract.timepoint(...), but the test WASM contract used to generate test-custom-types does not appear to export a timepoint function (it is commented out in cmd/crates/soroban-test/tests/fixtures/test-wasms/custom_type/src/lib.rs). This will fail TypeScript compilation or runtime once bindings are regenerated. Either remove this test, or (if timepoint/duration support is intended) uncomment/add the contract methods and ensure the generated bindings include them.
  cmd/crates/soroban-spec-typescript/ts-tests/src/test-custom-types.ts:229
• Same issue as above for contract.duration(...): the underlying test_custom_types contract fixture does not export duration (currently commented out), so this test will not compile/run against freshly generated bindings. Remove the test or update the fixture contract + regenerated WASM/bindings accordingly.

[leighmcculloch]

Reverted the formatting changes in the ts test files so the diff is just the networks.standalone → networks.local swap.

Also pushed a change that makes this non-breaking by emitting both keys when the passphrase is the Standalone Network passphrase. The primary key is local; standalone is kept as an alias with a JSDoc @deprecated so consumers regenerating bindings get an IDE warning but their code keeps compiling.

Generated output for the local case:

export const networks = {
  local: {
    networkPassphrase: "Standalone Network ; February 2017",
    contractId: "...",
  },
  /** @deprecated Use `local` instead. */
  standalone: {
    networkPassphrase: "Standalone Network ; February 2017",
    contractId: "...",
  },
} as const

Other networks (testnet, futurenet, unknown) are unchanged.

@fnando or @Ryang-21, could one of you take a look?