Bicep types are not generated for resources that use "name" as a polymorphic discriminator

[anthony-c-martin]

First reported under #656.

Some RPs define multiple resources of the same resourceType, with a fixed set of (or enum-valued) name values, with a different body shape depending on the value of name. This is problematic for child resources, because Bicep expects the fully-qualified name of the type.

resource myWebConfig 'Microsoft.Web/sites/config@2020-06-01' = {
  // because we're forced to use string interpolation, 'name' is not a compile-time value, and we cannot use it as a discriminator key to select the right type for the resource body
  name: '${myWebsite.name}/authsettings'
}

[anthony-c-martin]

Some possible solutions:

1. Special-case suffix-matching for interpolated strings when picking a path in an object discriminator (e.g. as long as the string ends in /authsettings, we can reliably pick a path).
2. Introduce a parent syntax so that child resources only need specify the child name - e.g.:

resource myWebConfig 'Microsoft.Web/sites/config@2020-06-01' = {
  parent: myWebsite // reference to parent resource
  name: 'authsettings' // this is now a constant type and can be used as a discriminator key
}

3. Create a merged object with all possible properties. This will be problematic for Microsoft.Web/sites/config in particular, because one of the polymorphic types is an open dictionary.

[slavizh]

btw as this is very much related to app services APIs is there any plan to have better intellisense for that API. Overall that API is tone of the worse as it is one thing build on top of another and they continue to do that (new logic app). For example depending on the kind value which is string and there you can have one value or multiple values separated by comma the properties for Microsoft.Web/sites resource will be different. Meaning that there could be some properties that are relevant for web apps only and some others only for container web apps and third for container web apps with linux, etc.

[bmoore-msft]

These are a pain for tooling... IDK if I completely follow your proposal but I think it has legs. Basically, for a singleton we'd have to give some indication, somewhere that's that what is it. Ideally, we could to this in the tooling/metadata rather than have the user specify. IOW, we know that web's "config" resource has additional information to specify it's "shape" - as @slavizh mentions this is usually "kind" or "sku" but the web api's predate those properties. We could emulate that behavior in these singleton's - either by the user specifying or by tooling keying off of the name somehow.

Not sure we need to solve this in V1 but good to keep in mind as we look at things like #127

[alex-frankel]

At minimum, we should treat this as "any" type so that it does not throw an error/warning

[miqm]

any update/ETA on this?

[alex-frankel]

No work has started. I think plan is to revisit this once #127 is done or as part of implementation of that feature. If using the new child resource syntax, we should be able to properly validate these resources

[miqm]

I noticed, that this might be also a problem in type generation itself, see Azure/bicep-types-az#101

[anthony-c-martin]

I noticed, that this might be also a problem in type generation itself, see Azure/bicep-types-az#101

You're correct - there's also some work we need to do type generation for this issue.