Linter rule to enforce "strict" keyword order

[alex-frankel]

Params and outputs should be grouped together, params should be at the top, outputs should either be underneath params or at the bottom of the file.

Open question whether this should also enforce strict ordering of module, resource, or var.

[verschaevesiebe]

Would agree here, as we're managing a lot of bicep files with our team I think it would favor consistency.
+1

[dciborow]

after reading the idea over here... https://github.com/orgs/Azure/projects/115/views/19

I rarely run into any issues with the "ordering" of my module keys. name, params are almost all that is ever needed, with scope rarely used. dependsOn is almost a sign that something is being done wrong, and is probably even more rarely used correctly then scope.

What I do find bothersome is the syntax differences between resources and modules. It makes it "tricky" (i dont want to say harder, but harder then it needs to be) to convert from using a resource to a module. I would prefer that the whole module syntax be more compatible with the resource syntex.

Given the following resource, a number of changes need to be made to make it a "module".

Currently

Before

ARM Template - main.bicep

resource stg 'Microsoft.Storage/storageAccounts@2019-06-01' = {
  name: 'examplestorage'
  location: 'eastus'
  sku: {
    name: 'Standard_LRS'
    tier: 'Standard'
  }
  kind: 'StorageV2'
  properties: {
    accessTier: 'Hot'
  }
}

After

1. Move location to params
2. Move skew to params as a complex object
3. move kind to params
4. Move properties.accTier from properties to params

ARM Template - main.bicep

module stg 'storageAccounts.bicep' = {
  name: 'examplestorage'
  params: {
    location: 'eastus'
    sku_name: 'Standard_LRS'
    sku_tier: 'Standard'
    kind: 'StorageV2'
    accessTier: 'Hot'
  }
}

Module File - storageAccounts.bicep

param name string
param location string
param sku_name string
param sku_tier string
param kind string = 'StorageV2'
param accessTier string = 'Hot'

resource stg 'Microsoft.Storage/storageAccounts@2019-06-01' = {
  name: name 
  location: location 
  sku: {
    name: sku_name 
    tier: sku_tier 
  }
  kind: kind 
  properties: {
    accessTier: accessTier 
  }
}

Proposed

Enable removing the need for the "paras" key from Bicep modules completely. (for backwards compatibility, having a params key should still be allowed, but users should not be able to mix and match) Lastly, I should be able to use any ARM object type as a bicep type, instead of being limited to object. Without this, I need to pop every key of properties into its own new parameter. I can try to use the object type, but it becomes very complicated if a user wants to override some, but not all the defaults.

main.bicep

module stg './storageAccounts.bicep' = {
  name: 'examplestorage'
  location: 'eastus'
  sku: {
    name: 'Standard_LRS'
    tier: 'Standard'
  }
  kind: 'StorageV2'
  properties: {
    accessTier: 'Hot'
  }
}

Module File

param location

param sku Sku = {
  name: 'Standard_LRS'
  tier: 'Standard'
}

param kind string = 'StorageV2'

param properties StorageAccountPropertiesCreateParametersOrStorageAccountProperties = {
  accessTier: 'Hot'
}

resource stg 'Microsoft.Storage/storageAccounts@2019-06-01' = {
  name: name 
  location: location 
  sku: sku 
  kind: kind 
  properties: properties
}

sku
storageaccountpropertiescreateparametersorstorageaccountproperties

[StephenWeatherford]

@dciborow See #8522