Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for precompiler directives like #include or #import #7726

Closed
TazzyMan opened this issue Jul 27, 2022 · 3 comments
Closed

Support for precompiler directives like #include or #import #7726

TazzyMan opened this issue Jul 27, 2022 · 3 comments
Labels
enhancement New feature or request Needs: Triage 🔍

Comments

@TazzyMan
Copy link

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.

@TazzyMan TazzyMan added the enhancement New feature or request label Jul 27, 2022
@ghost ghost added the Needs: Triage 🔍 label Jul 27, 2022
@jeskew
Copy link
Contributor

jeskew commented Jul 28, 2022

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?

@TazzyMan
Copy link
Author

@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.

@alex-frankel
Copy link
Collaborator

I'm going to close this as a duplicate of #363.

Also related to #2374

@ghost ghost locked as resolved and limited conversation to collaborators May 25, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request Needs: Triage 🔍
Projects
None yet
Development

No branches or pull requests

3 participants