Repository navigation
simplify import_contract! testing #65
Description
On testnet & mainnet, import_contract! is great, but in dev and testing it has some frustrations. This is highlighted by:
- feat!: simplify with new
import_contract!macro contracts#24 - feat: support SAC and XLM in import_contract! #64 (comment)
#64 has an elegant workaround for testing. Without including this in the macro somehow, probably lots of teams will retrace the same steps when they adopt import_contract!. Given that we already came up with an elegant solution here, can we incorporate it into the library itself, so consumers have an easier dev/testing experience?
Activity
pselle commentedon Oct 14, 2026
Describing the plan of action here:
First,
stellar-registrywill get atestutilsfeature withregister_import!. It resolves a name the same wayimport_contract!does and registers the imported contract at the address baked in at build time. It registers either the cached Wasm, optionally with constructor args, or a native mock (#77). Next,register_import!supports Stellar Asset Contracts by placing a mintable test asset at the baked SAC address (#82). Then a newstellar registry local upcommand bootstraps a local network with the registry deployed, so imports can resolve against it during development.Once those are released, a PR in stellar-registry/contracts will switch registry-tansu-manager to
import_contract!, test it withregister_import!and uselocal upin its justfile. That PR closes this issue.chadoh commentedon Oct 15, 2026
Overall, I really like this plan! Just one question:
stellar container start local(andstellar scaffold watch, which automatically runsstellar container startand waits for it to be healthy, if the scaffold config specifies this) already starts the local network. I don't think we should duplicate that logic in Registry CLI. But maybelocal upcould check that the local network is already running and deploy the Registry contract, if needed?Thinking about it more:
local upreads nicely but are there other subcommands underlocal? If not,local-upor some other name might be better, so anyone exploring with-hdoesn't need to dig so far.register_import!check if the contract is deployed, and deploy it if not? Then we don't need thelocal upcommand at all.chadoh commentedon Oct 15, 2026
Oh wait hm, during development. 🤔 How would that actually work? 🤔 Dev build doesn't use
test_utilsorregister_import!. Doeslocal upuse the test setup? Or does it do something else with theimport_contract!macro?pselle commentedon Oct 15, 2026
stellar registry local upYeah, that's fair, let's not duplicate the network bit.And namespaces: Yes, simpler when we can.
local-upsounds fine.register_import!is only for testing purposes, whilelocal-upis for dev builds soimport_contract!can look up addresses on the local registry at build time. The two things live in different worlds, reallychadoh commentedon Oct 15, 2026
Talking this through with @zachfedor, here's what we thought made sense:
testing:
register_import!is great! Seems like exactly the tool for the job. (PR review incoming on feat: add register_import! for testing import_contract! callers #77)local dev: if
STELLAR_NETWORK == "local"and local Registry contract is not deployed or the requested contract is not registered in it, fail with an error that says something like:The "configure local dev env with Registry contract & local registered contracts" is still TBD on the Scaffold side, but that seems like the tool for the job. Let's not re-implement with separate logic here. No
local-upCLI command.Does that make sense to you?
Should we also default to testnet, rather than local?
pselle commentedon Oct 15, 2026
Makes sense. Let's drop
local-upand leave local setup to Scaffold. I'll makeimport_contract!(andimport_contract_client!) fail with that error whenSTELLAR_NETWORK=localand the Registry or the contract isn't there.I'd keep
localas the default, though. Right now an unconfigured build fails noisily. If we default to testnet, it would quietly bake testnet addresses into the contract, and then that could easily go to mainnet, whatever.localis also the default for the cache path instellar-buildand for computing asset contract addresses, so switching would mean changing Scaffold too. I'd rather keep the loud failure and let the new error point people in the right direction.pselle commentedon Oct 15, 2026
Restatement of the plan, adjusting for "what should happen to run things locally?"
First,
stellar-registrywill get atestutilsfeature withregister_import!. It resolves a name the same wayimport_contract!does and registers the imported contract at the address baked in at build time. It registers either the cached Wasm, optionally with constructor args, or a native mock (#77). Next,register_import!supports Stellar Asset Contracts by placing a mintable test asset at the baked SAC address (#82).For local development, the Registry CLI won't set up the local network itself. When
STELLAR_NETWORK=localand the local Registry is missing or doesn't have the requested contract,import_contract!will fail with a clear error that points to Stellar Scaffold, which will own local setup.localstays the default network.The hello_caller and xlm_tip_jar fixtures in this repo show the full pattern and run in CI, so this issue can close once these are released. registry-tansu-manager, the original motivating case, has moved to Tansu’s repo (stellar-registry/contracts#55), so stellar-registry/contracts#24 can be closed rather than updated.
chadoh commentedon Oct 15, 2026
That all sounds good though I would like us to implement this somewhere in our own contracts. We could send an update like stellar-registry/contracts#24 to the Tansu repo, or we could update Scaffold's template, or... What other cross-contract calls are we making?