Minor Edge Cases for Bicep

[dciborow]

Love this tool! Trying it out with Azure Bicep. Works better than anything else out there, but a few edge cases that could be even better. Going to see what I can do.

Case 1

Raw

@description('VNET resource group name.')
param vnetResourceGroupName string
param vnetName string = 'HXVNET'
param p4SubnetName string = 'PublicSubnet0'
param p4NicName string = 'hxnic'
@description('Name of the public IP to assign for NIC')
param p4PublicIPName string = 'hxcorepip'

Current

Preferred

@description('VNET resource group name.')
param vnetResourceGroupName string
param vnetName              string = 'HXVNET'
param p4SubnetName          string = 'PublicSubnet0'
param p4NicName             string = 'hxnic'
@description('Name of the public IP to assign for NIC')
param p4PublicIPName        string = 'hxcorepip'

Case 2

Input

var p4CmdToRun = 'sudo /usr/local/bin/signal.sh >> /var/log/userdata.log 2>&1'
var vnetID = resourceId(vnetResourceGroupName, 'Microsoft.Network/virtualNetworks', vnetName)
var imageReferenceSource = {...
}
var planReferenceSource = {...
}

Current

Preferred

var p4CmdToRu            = 'sudo /usr/local/bin/signal.sh >> /var/log/userdata.log 2>&1'
var vnetID               = resourceId(vnetResourceGroupName, 'Microsoft.Network/virtualNetworks', vnetName)
var imageReferenceSource = {...
}
var planReferenceSource  = {...
}

Case 3

Raw

resource p4PublicIPName_resource 'Microsoft.Network/publicIPAddresses@2020-08-01' = {...
}

resource p4NicName_resource 'Microsoft.Network/networkInterfaces@2020-08-01' = {...
}

Current

Prefered

resource p4PublicIPName_resource 'Microsoft.Network/publicIPAddresses@2020-08-01' = {...
}

resource p4NicName_resource      'Microsoft.Network/networkInterfaces@2020-08-01' = {...
}

[OldStarchy]

I think this can be implemented with a rewrite, though I haven't fleshed out my idea fully yet. The current system is not super flexible, and as you've probably noticed, it can't deal with gaps in groups.

My current thinking is to implement some group definition/matcher, which would essentially be a glorified regex pattern. Each regex group can be used to group and align the content. For case 1 /^(param \w+ ?)(string(?: = .*$))/, case 2 /^(var \w+ )(= .*)^/, etc. A more generic set of regex (and language-specific ones) can be created. Matchers can be given a limit on how many non-matching lines are allowed in a row before the group will end, or specifically what patterns are allowed within a group without ending it. Doing this semantically would be better but is OoS for this extension (at least for the foreseeable future).

Though this does raise the issue of nested groups.

const a   = 1;      // Group 1
const aa  = 1;      // Group 1
const aaa = () => { // Group 1
  const bbb = 1; // Group 2
  const b   = 1; // Group 2
}; // Ignored
const a   = 1;      // Group 1

Though maybe I can skip over folded regions (assuming there's an API for that) rather than only relying on the text content.

Also, as we know regex isn't recursive, so matching n+ groups can't be done just with one regex, and perhaps any remaining characters after the initial group match can be handled by the current implementation that just tries to match like-operators.

const a = a + aa + aaaa + aaaaaa;
const b = b + b  + b    + b;