Feature request: Reusable parameter definitions across Bicep templates

[johnlokerse]

Is your feature request related to a problem? Please describe.
It's not a problem, but this is related to the repetition of Bicep template parameters.

Describe the solution you'd like
Currently, we have a feature to export and import variables and user-defined functions, allowing us to avoid code repetition (DRY). I would like to see this extended to parameter definitions in .bicep templates.

I have seen many infrastructure projects where parameters are reused across different Bicep template files. This results in copying and pasting parameter definitions between templates, and when a parameter changes, it needs to be updated in all those templates. The same applies to changes to decorators such as @allowed.

There are probably better implementation scenarios, but I would like to start a discussion on this topic. Here is an approach that would help avoid repetition:

1. A new file extension called .bicepextension is introduced. In this file, you can define a set of parameters that can be extended from:

@allowed([
	'prd'
	'acc'
	'dev'
	'sbx'
])
param environment string

param location string

2. A Bicep template uses the extends keyword, with an additional keyword params to indicate parameter extension from a .bicepextension file, e.g. extends params base.bicepextension:

extends params base.bicepextension

param mySpecificParametersHere string

resource myResourcesHere '...' = {
	location: location
	name: 'my-resource-${environment}'
	properties: {
		something: mySpecificParametersHere
	}
}

Or the approach to use include <path to bicep file> would be something to explore too:

include base.bicep

param mySpecificParametersHere string

resource myResourcesHere '...' = {
	location: location
	name: 'my-resource-${environment}'
	properties: {
		something: mySpecificParametersHere
	}
}

This approach allows users to define base parameter definitions and avoid parameter repetition. It is similar to how we can currently use parameter value sharing in Bicepparam (via the experimental feature).

Potential duplicates

I tried to search for other feature requests similar to mine and found these two asking for somewhat the same feature, but in a different way:
#17053
#17609

I would like to hear your thoughts/opinion on this topic: @slavizh, @anthony-c-martin, @jeskew and @riosengineer.

[riosengineer]

I know we’ve spoken about this already, and I think we’re on the same page.

A common tedious pain point is having to constantly repeat param definitions across multiple templates. There is usually a common set of param definitions that we use consistently across all templates. Having a way to centralise, standardise and import / extend these into templates would be a great QoL win.

Where possible I use imports, but we are limited to vars and types. So, it does leave a gap around parameter definitions.

An example where this would clearly enhance authoring experience:

1. I have a large mono Bicep repo for landing zones (platform + app).
2. Cloud teams copy and paste common parameter definitions into new templates when authoring.
3. This leads to inconsistencies in descriptions and parameter definitions, causing drift across large repos.

Having a way to extend a default param definition set would eliminate the above. And potentially have additional benefits:

• I can standardise descriptions for common parameter definitions without others copying/pasting and changing them, which often leads to errors and misconfigurations.
• It could allow me to upload these to a central ACR for my organisation to consume across multiple projects/repos/platforms, for example, from a GitHub org to multiple Azure DevOps projects or across AzDo orgs.
• I can then run unit tests to ensure templates are using the common Bicep parameter definitions or fail PR checks if they’re not.

[guimatheus92]

This is an amazing request and can ease the process of maintaning so much paramaters, specially templates that has lots of them.

@anthony-c-martin if I understood correctly, this is very similar to scopeBindings.json, that is used from EV2, as a source of parameters values. This could close another gap from EV2.

Really nice idea!

[aavdberg]

Sounds good.