You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As soon as you start to really use bicep, files grow quickly. Not as fast as ARM templates, but still very fast.
As of now there is no way to split your bicep up in multiple files, except for modules, which isn't the same, as it's imported as a deployment and is run seperately, causing all kinds of issues with 'dependsOn'.
I would like a way to split the file up into multiple managable parts, to make things a bit more readable. All these files will be combined in a single bicep file before it's compiled to an ARM template, so there needs to be no change to the ARM compiler itself.
Something like:
#import './library/appServicePlan'
// other bicep...
#import './library/appService'
The most ideal situation would be if there would be support for 'functions', so parts of it could be reused more easily:
#import plan './library/appServicePlan' = {
name: 'myappServicePlan'
kind: 'functionapp,workflowapp'
parameter3: 'can only be constant since nothing is executed yet '
}
Maybe later there could be support for precompile time expressions (string calculations) and variables, so the reuse value is increased even further, but I would be very happy if the first two options are included.
The text was updated successfully, but these errors were encountered:
The behavior proposed is similar to what's discussed in #3355, #6459, and #514, though there are some syntactic differences. Would the anonymous modules feature of #3355 meet your requirements?
@jeskew As far as I can see #514#6459 work the other way around (arm to bicep and export/decompile to multiple files) #3355 is about leaving out the name parameter for modules, but your comment, and especially bullet #2 is certainly linked to this proposal.
However this proposal extends on that idea by not only allowing to split the file up into multiple files, but also use some templating. In the current form, when not using modules, you'll have to include the same code multiple times, or use the '[for' statement to create multiple instances of the same resource, when you only want to change one or two properties.
In mij proposal every '#' statement is preprocessed to an in-memory bicep file, which can then just be compiled to an ARM template. That would include importing the contents of other files and even changing some parameter values along the way.
The result would be the same big file you need to create manually now.
I chose '#' because it's used for precompile directives in a lot of languages.
As soon as you start to really use bicep, files grow quickly. Not as fast as ARM templates, but still very fast.
As of now there is no way to split your bicep up in multiple files, except for modules, which isn't the same, as it's imported as a deployment and is run seperately, causing all kinds of issues with 'dependsOn'.
I would like a way to split the file up into multiple managable parts, to make things a bit more readable. All these files will be combined in a single bicep file before it's compiled to an ARM template, so there needs to be no change to the ARM compiler itself.
Something like:
The most ideal situation would be if there would be support for 'functions', so parts of it could be reused more easily:
Maybe later there could be support for precompile time expressions (string calculations) and variables, so the reuse value is increased even further, but I would be very happy if the first two options are included.
The text was updated successfully, but these errors were encountered: