Import all params from a template as a User-Defined type
- Dominant language
- Bicep
- Stars
- 3.6k
- Forks
- 830
- Avg merge
- 1d 21m
- Merged PRs (30d)
- 79
Description
**Is your feature request related to a problem? Please describe.**
More often than not when creating .bicep templates, my templates consume other modules. Most of the time, AVM resource modules.
A common pattern is then to again use .bicepparam files for different deployments. For example a .bicepparam file per environment.
This becomes very cumbersome when it comes to parameters and parameter naming. Essentially chaining parameters up in the template and parameter file chain.
A very common scenario is a subscription scoped deployment, consuming two AVM modules.
- Resource Group
- Some other resource module, like a VM for example.
Sure, we have the AVM convention [pmnfr5](https://azure.github.io/Azure-Verified-Modules/specs/bcp/ptn/#id-pmnfr5---category-inputs---parametervariable-naming) for naming parameters, but it's quite labour-intensive to implement properly.
Take the following example.
Of course, in this example, where the modules only expose two simple parameters each, it is not an issue, however, consider if it was the virtualMachine module for example, I think it has 76 parameters.
So just a very simple deployment, like the one described above with a resource group and a VM can become hugely complex.
```bicep
// avm-mock1.bicep
param name string
param size string
...
```
```bicep
// avm-mock2.bicep
param name string
param sku string
...
```
```bicep
// main.bicep
param mock1Name string
param mock1Size string
param mock2Name string
param mock2Sku string
module mock1 'avm-mock1.bicep' {
params: {
name: mock1Name
size: mock1Size
}
}
module mock2 'avm-mock2.bicep' {
params: {
name: mock2Name
sku: mock2Sku
}
}
...
```
**Describe the solution you'd like**
I think this could be solved quite elegantly in Bicep itself using the UDT feature and possibly the spread operator.
There would be multiple syntax variants for this, but one suggestion could be using a special `params` keyword in the import statement, and adding support for the `...` spread operator in the params block of modules.
```bicep
// avm-resource-group.bicep
param name string
param tags object?
...
```
```bicep
// avm-vm-module.bicep
param name string
param sku string
...
```
```bicep
// main.bicep
// Custom pattern module
import params as resourceGroupParamsType from 'avm-resource-group.bicep'
param resourceGroupParams resourceGroupParamsType
import params as vmParamsType from 'avm-vm-module.bicep'
param vmParams vmParamsType
module rg 'avm-resource-group.bicep' {
params: resourceGroupParams
}
module vm 'avm-vm-module.bicep' {
params: {
...vmParams
sku: 'override-value'
}
}
...
```
Contributor guide
Research direction
Start by reviewing the example avm-resource-group.bicep, avm-vm-module.bicep, and main.bicep snippets, then investigate the existing Bicep user-defined type, import, and module-parameter entry points. Done means agreeing on syntax and semantics, supporting imported parameter types and spread values, and covering the behavior with tests.
Written by the indexing model from the issue text.
Assessment
- Domain
- compilers
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100