Add basic workspace example that contains multiple contracts that are developed in close proximity to each other, and uses the native builds of the contracts, not the wasm builds, for all tests.
Why
For a long time developing for workspaces wasn't a topic we addressed because developing for a workspace of multiple contracts was no different than developing for multiple contracts at arms length.
When developing contracts at arms length the recommendation is to import those arm length dependencies as .wasm files. This has several advantages: developing against the actual dependency as it will be deployed, separating upgrades of SDK versions across contracts, source code isn't required. A significant amount of effort has gone into making this workflow smooth, so it is relatively smooth.
This example demonstrates how, using the SDK available today, it is possible to develop contracts in close proximity in a workspace where all testing is done using natively loaded contracts.
There are several advantages to this:
It can be easier to share types across multiple contracts.
It can be easier to step-through-debug in integration tests that span all contracts in the workspace.
There are several rough edges in this workflow:
It's not ideal to import contracts into one another for the final builds, because the exports of all contracts will be combined into all builds. This is a side-effect of how Rustc works. So while we can import contracts, it's limited to in the test builds, i.e. dev_dependencies in the Cargo.toml, unless we add features to all contracts to enable importing them without exports. We had that in the past, but it was confusing.
Because of the prior point any shared contract interfaces need to be defined in separate crates.
Contracts in the workspace all need to be using the same SDK version for running local tests, unless separate tests are written that use .wasm.
What
Add basic workspace example that contains multiple contracts that are developed in close proximity to each other, and uses the native builds of the contracts, not the wasm builds, for all tests.
Why
For a long time developing for workspaces wasn't a topic we addressed because developing for a workspace of multiple contracts was no different than developing for multiple contracts at arms length.
When developing contracts at arms length the recommendation is to import those arm length dependencies as .wasm files. This has several advantages: developing against the actual dependency as it will be deployed, separating upgrades of SDK versions across contracts, source code isn't required. A significant amount of effort has gone into making this workflow smooth, so it is relatively smooth.
This example demonstrates how, using the SDK available today, it is possible to develop contracts in close proximity in a workspace where all testing is done using natively loaded contracts.
There are several advantages to this:
There are several rough edges in this workflow:
Related to https://github.com/stellar/stellar-docs/issues/481