Including enums brings tons of unnecessary code into the bundle

[msklvsk]

If you do

import { IHumanName } from '@ahryman40k/ts-fhir-types/lib/R4'
import { HumanNameUseKind } from '@ahryman40k/ts-fhir-types/lib/R4/Resource/RTTI_HumanName'
let name: IHumanName = {
    use: HumanNameUseKind._maiden,
}
// […] use the `name` var in some way

and webpack it, it’ll bring ~75K of stuff from typescript-fhir-types and io. And if you include HumanNameUseKind from @ahryman40k/ts-fhir-types/lib/R4, it’ll bring the entire library into the bundle.

If only we could use string literal types instead of enums… This would allow type-only imports, with zero code actually require()d.

[Ahryman40k]

Hi,

It exists a union type that force everything to be included, it's a part of the FHIR object definition. There are ways to avoid that, but I lack of free time.

I guess there was reasons behind the enum type, but I can't remember ... Maybe it was just a lack of maturity with Typescript.

Feel free to contribute a produce a Pull Request. Cheers

[preston]

FWIW this issue also exists in Microsoft's https://github.com/microsoft/fhir-codegen .

@Ahryman40k Are you intending on maintaining this project? We might be interested in helping and really appreciate the work!

[Ahryman40k]

Hi @preston,

I'm happy to discover that Microsoft doesn't do better than I can :) But to be frank, it's an issue from the FHIR definition itself. There is a way to solve it and I tried to rewrite my code generator several times for that purpose and also to reduce the generated code files. Unfortunately, because of major changes in my life in the last 2 years, I was unable to achieve that goal. The project is currently in minimal maintenance because, for a few months, you are able to use @types/fhir. It only declares types and if you need runtime type checking, you have to produce your own.

Hope It answers your questions.