Feature Request: Generate Typescript enums for "type": [{ "code": "code" }] elements

[joepaquette]

Generate and export Typescript enums for "type": [{ "code": "code" }] elements using the associated "short" element values (e.g., DocumentReference.status and DocumentReference.docStatus in the documentreference.profile.canonical.json profile) referencing the associated binding.valueSet from the canonical.json files.

These generated enums would only be exported as a convenience for developers to use in their code when setting code values in the actual data objects that implement the generated interfaces. I'm NOT suggesting that they would be used or referenced in any way within the generated interfaces.

Example:
`
/**
* DocumentReference.status
* Ref: http://hl7.org/fhir/valueset-document-reference-status.html
*/
enum DocumentReferenceStatus {
CURRENT = 'current',
SUPERSEDED = 'superseded',
ENTERED_IN_ERROR = 'entered-in-error',
}

/**
* DocumentReference.docStatus
* Ref: http://hl7.org/fhir/valueset-composition-status.html
*/
enum DocumentReferenceDocStatus {
PRELIMINARY = 'preliminary',
FINAL = 'final',
APPENDED = 'appended',
AMENDED = 'amended',
ENTERED_IN_ERROR = 'entered-in-error',
}
`

[tangdrew]

This is a good idea as a configurable behavior for fhir-ts-codegen. I think it could be nice to generate TypeScript enums for code elements that are bound to ValueSets with required binding-strength. This is probably lower on my list of priorities while I'm working on getting fhir-types compliant against the base spec, like supporting choice types. But I'd happily accept contributions if you need this feature before I get around to it!

[joepaquette]

I agree with the "configurable behavior" and it being a low priority. We don't need this feature any time soon, but if our priorities change, I'd be happy to create a pull request for you.

I'm not sure how feasible or even useful, generating enums for codes in ValueSets would be. These lists tend to be large and typically from external sources. Tying into a terminology service or some other lookup mechanism might make more sense for these.

As a nice-to-have feature added at some point down the road, I think generating stand-alone enums for the codes associated with code datatypes specified internally within the StructureDefinition (profile) would be sufficient. These tend to be lists with a limited list of codes and would be much more manageable. I wouldn't even reference them in the generated interfaces.