Develop

[atoumbre]

This PR refactors the way we handle custom environment-based building blocks. Previously, we used two separate traits — ToEncode and EnvironmentEncode — to manage encoding logic. This approach has now been streamlined.

What's Changed

Instead of relying on custom encoding traits, we now focus on converting environment variables directly into ManifestValue. These values are then passed normally to the manifest_args!() macro, eliminating the need for additional encoding logic and simplifying the interface.

To support this, the new ToValue trait has been introduced:

pub trait ToValue {
    fn to_value<'a>(
        &self,
        test_engine: &mut TestEngine,
        manifest_builder: ManifestBuilder,
        caller: ComponentAddress,
    ) -> (ManifestBuilder, ManifestValue);
}

Benefits

• Simplifies the process of supporting custom types in test manifests.
• Reduces boilerplate and avoids redundant trait implementations.
• Enables cleaner, more expressive code when dealing with environment variables.

Example: Handling Optional Environment Variables

We’ve introduced an EnvOption enum to model optional environment values, along with its ToValue implementation:

pub enum EnvOption {
    None,
    Some(Box<dyn ToValue>),
}

impl ToValue for EnvOption {
    fn to_value(
        &self,
        test_engine: &mut TestEngine,
        manifest_builder: ManifestBuilder,
        caller: ComponentAddress,
    ) -> (ManifestBuilder, ManifestValue) {
        match self {
            EnvOption::Some(element) => {
                let (manifest_builder, inner_value) = element.to_value(test_engine, manifest_builder, caller);
                (
                    manifest_builder,
                    Value::Enum {
                        discriminator: 1,
                        fields: vec![inner_value],
                    },
                )
            }
            EnvOption::None => (
                manifest_builder,
                Value::Enum {
                    discriminator: 0,
                    fields: vec![],
                },
            ),
        }
    }
}

Additional Improvements

We also added dedicated environment types for the four supported address kinds:

• EnvResource
• EnvAccount
• EnvComponent
• EnvPackage

This makes it easier to implement custom types and simplifies manifest parameter construction.

Example: Custom Tuple Type

Here’s how we define a custom type representing a (ComponentAddress, FungibleBucket) tuple:

struct CustomType<N: ReferenceName + Clone, T: ResourceReference + Clone>(
    EnvComponent<N>,
    Fungible<T>,
);

impl<N: ReferenceName + Clone, T: ResourceReference + Clone> ToValue for CustomType<N, T> {
    fn to_value(
        &self,
        test_engine: &mut TestEngine,
        manifest_builder: ManifestBuilder,
        caller: ComponentAddress,
    ) -> (ManifestBuilder, ManifestValue) {
        let (manifest_builder, address) = self.0.to_value(test_engine, manifest_builder, caller);
        let (manifest_builder, bucket) = self.1.to_value(test_engine, manifest_builder, caller);

        let value = Value::Tuple {
            fields: vec![address, bucket],
        };

        (manifest_builder, value)
    }
}

---

Let me know if you'd like a shorter version for internal use or one tailored for external contributors!