Is your feature request related to a problem?

Yes. When using the {{ source prevSourcename }} syntax together with dependsOn, there are scenarios where you need to manipulate the source output value before using it. For example:

• Source outputs a version like "1.2.3" but you need it as "1_2_3" (replacing dots with underscores)
• Source outputs a value that needs case transformation (uppercase/lowercase)
• Source outputs a value that needs multiple character replacements or transformations

Currently, there's no way to manipulate the output of the {{ source }} function at runtime, which limits flexibility when the source output format doesn't match the required format for downstream resources.

Solution you'd like

Enable pipe operations (using sprig template functions) on the output of the {{ source }} function at runtime. This would allow users to chain template functions to transform the source output value.

Example usage:

# Replace dots with underscores
sourceid: '{{ source prevSourcename | replace "." "_" }}'

# Chain multiple transformations
sourceid: '{{ source prevSourcename | replace "." "_" | replace "-" "_" }}'

# Case transformations
name: '{{ source prevSourcename | upper }}'
name: '{{ source prevSourcename | lower }}'

# In target sourceid
targets:
  update:
    sourceid: '{{ source "version" | replace "." "_" }}'

How it works:

1. The {{ source prevSourcename }} function evaluates first and returns the source output (e.g., "1.2.3")
2. The pipe operator (|) passes that value to the next function
3. The transformation function (e.g., replace "." "_") processes the value
4. The final transformed value is used (e.g., "1_2_3")

Alternatives you've considered

1. Using transformers on the source itself: This would transform the source output globally, but sometimes you need different transformations in different places (e.g., one target needs 1_2_3 while another needs 1-2-3).

2. Pre-processing the source name: This doesn't work because you need to manipulate the source output, not the source name.

3. Creating intermediate sources: This adds complexity and requires maintaining multiple sources for what is essentially a formatting difference.

4. Post-processing in targets: Not all target types support this, and it's less flexible than template-based transformations.

Implementation Details

This feature requires:

• Adding sprig template functions to the runtime template processing (when {{ source }} is evaluated)
• Ensuring pipes work correctly with the source function return value
• Maintaining backward compatibility with existing {{ source }} usage

Technical approach:

• The runtime template processing in pkg/core/config/main.go should include sprig functions via sprig.FuncMap()
• This enables all sprig string manipulation functions (replace, upper, lower, trim, etc.) to work with source output
• The pipe mechanism is already supported by Go templates, it just needs the functions to be available

Benefits

1. Flexibility: Users can transform source output values to match different requirements
2. No breaking changes: Existing {{ source }} usage continues to work unchanged
3. Powerful: All sprig string functions become available (replace, upper, lower, trim, substr, etc.)
4. Consistent: Uses the same template syntax and pipe mechanism already familiar to users
5. Useful for dependsOn scenarios: When a target depends on a source and needs the value in a different format

Example Use Cases

1. Version format conversion: Source outputs "1.2.3" but target needs "1_2_3" for a filename or environment variable
2. Case normalization: Source outputs "V1.2.3" but you need "v1.2.3" consistently
3. Character sanitization: Source outputs a value with special characters that need to be replaced for use in identifiers
4. Multiple transformations: Chain several operations to achieve complex formatting requirements

Anything else?

This feature would significantly improve the flexibility of updatecli when working with source outputs, especially in scenarios involving dependsOn where you need to reference and transform source values. The implementation leverages existing Go template and sprig functionality, making it a natural extension of the current template system.