Ensure shorter tokens for object types

[t0yv0]

Hello!

• Vote on this issue by adding a 👍 reaction
• If you want to implement this feature, comment to let us know (we'll work with you on design, scheduling, etc.)

Issue details

When mapping deeply nested TF properties to Pulumi Package Schema .types section, tfgen needs to pick "tokens" to identify every record/object type it encounters, and sometimes it picks very long tokens. Unfortunately these tokens are not simply abstract identifiers, but are used by every language codegen (C#, Py, TS, Java, Go) to pick names for classes representing these structures. This can lead to very long class names, because the current naming heuristic makes the name O(N) in the depth of property.

Example of an unusable name:

TemplateDefinitionSheetVisualGeospatialMapVisualChartConfigurationFieldWellsGeospatialMapAggregatedFieldWellsValueNumericalMeasureFieldFormatConfigurationNumericFormatConfigurationPercentageDisplayFormatConfigurationSeparatorConfigurationThousandsSeparator

In languages that require file-per-class this additionally creates problems with very long filenames.

The feature request is to make a change to generate shorter tokens for object types. This is scoped to only types of resource/datasource/provider properties, and will not change anything for types representing resources, datasources or provider config itself. The change will make codegen class names shorter, easier to work with, more pleasant, and avoid hard limits on filenames in languages such as C#.

The last bit of the token must be shorter than 256 as that is where codegen breaks. Arguably we can also have a smaller cutoff like 120 for aesthetic reasons. We can make this configurable defaulting to some reasonable value.

Note that this change will be technically breaking, because it will translate to auxiliary types being moved, and some programs depending on the old location of these types will be broken with the update. To mitigate the break, we need to ensure that an escape hatch is available for the bridged provider maintainer to hand-write a token of a given auxiliary type. It looks like .Type or .NestedType fields on SchemaInfo may help with this purpose but we need to confirm as it's not obvious. The expectation is that the maintainers will chose to mostly accept shorter names as a "welcome breaking change", but make exceptions for auxiliary types that happen to be widely used, based on user feedback.

Affected area/feature

[t0yv0]

Noting some comments per @danielrbradley

Scoping per resource may be beneficial for gradual rollout instead of switching the default wholesale, something that abstracts ObjectTypeNamingStrategy parameter, keep current strategy as the default but allow to opt-in to shorter names per resource/datasource. For ecosystem team we can also have a way to option to a different global strategy if need that, say on larger providers like OCI.

[t0yv0]

Note it looks like .Type/.NestedType cannot be relied right now to influence the picked tokens, so that is definitely something that we need to make sure is available here.

[t0yv0]

@mjeffryes this is the exciting ticket I was thinking of.