babelfhir-ts 1.0.18 → 1.0.25

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -2,12 +2,6 @@
2
2
 
3
3
  **BabelFHIR-TS** transforms FHIR® StructureDefinitions into production-ready TypeScript code with full type safety and built-in validation. Unlike generic FHIR type definitions, BabelFHIR-TS generates **profile-aware** interfaces that understand your Implementation Guide's constraints, extensions, and slicing rules.
4
4
 
5
- ## Why BabelFHIR-TS?
6
-
7
- **The FHIR Challenge**: Implementation Guides define strict profiles that constrain base FHIR resources with required or must-support elements, custom extensions, value set bindings, and cardinality rules. Existing TypeScript libraries can't capture these requirements when you need profile-specific types, leading to an overhead when using TypeScript to build apps that interact with FHIR servers.
8
-
9
- **The BabelFHIR-TS Solution**: Automatically generates TypeScript interfaces and validation logic directly from StructureDefinition JSON. Your IDE autocompletes required fields, flags missing extensions at compile-time, and validates FHIRPath invariants at runtime.
10
-
11
5
  ### What you get
12
6
 
13
7
  - **Strongly typed interfaces** that merge profile constraints with base FHIR types (types come from `@types/fhir`)
@@ -19,8 +13,6 @@
19
13
  - **Fast and lightweight**—minimal runtime deps; only `fhirpath` is required for validators
20
14
  - **Install any FHIR profile as a node module**—use `babelfhir-ts install` to add Implementation Guides directly to your project
21
15
 
22
- Use it to build FHIR-compliant APIs, validate incoming resources against profiles, or generate type-safe client SDKs from Implementation Guides.
23
-
24
16
  ## Installation
25
17
 
26
18
  Install globally (recommended when using the CLI frequently):
@@ -82,31 +74,32 @@ Generated profile packages installed via `babelfhir-ts install` are published as
82
74
  - `@types/fhir` is included as a dependency of the generated package (no extra setup in your app)
83
75
  - `fhirpath` is a peer dependency (required only if you use the generated validators/classes)
84
76
 
85
- Install `fhirpath` in your app if you plan to call `.validate()` or use the generated classes:
77
+ Install `fhirpath` in your app if you plan to call `.validate()` or use the generated classes.
86
78
 
87
- ```bash
88
- npm install fhirpath
89
- ```
79
+ ### Module resolution
80
+
81
+ Generated packages use **`moduleResolution: "node16"`** in their `tsconfig.json` to ensure proper ESM compatibility. This works with all modern TypeScript setups including:
82
+
83
+ - **Node.js 18+** with `"type": "module"` in `package.json`
84
+ - **Bundlers** (Vite, esbuild, Webpack) with ESM output
85
+ - **TypeScript 5.0+** with `node16`, `nodenext`, or `bundler` module resolution
86
+
87
+ #### FHIR type imports
90
88
 
91
- Import and use:
89
+ Generated code imports base FHIR types from `"fhir/r4"`:
92
90
 
93
91
  ```ts
94
- // TypeScript or JavaScript
95
- import { AdmissionAppointment, AdmissionAppointmentClass } from "pink.admission-generated";
96
-
97
- // Types are available automatically via .d.ts
98
- const appt: AdmissionAppointment = {
99
- resourceType: "Appointment",
100
- status: "booked",
101
- start: "2025-10-23T14:00:00Z",
102
- };
103
-
104
- // Optional helper class + validation
105
- const instance = AdmissionAppointmentClass.random();
106
- const result = await new AdmissionAppointmentClass(appt).validate();
107
- console.log(result.errors, result.warnings);
92
+ import { Appointment, Extension, CodeableConcept } from "fhir/r4";
108
93
  ```
109
94
 
95
+ Since `@types/fhir` doesn't provide a `package.json` `exports` field, BabelFHIR-TS includes an **ambient module declaration** (`fhir-r4.d.ts`) in every generated package. This declaration file:
96
+
97
+ - Maps `"fhir/r4"` imports to the actual `@types/fhir` type definitions
98
+ - Enables strict `node16`/`nodenext` module resolution without path configuration
99
+ - Is automatically picked up by TypeScript—no `tsconfig.json` changes needed in your project
100
+
101
+ > **Note**: If you're using `moduleResolution: "bundler"` in your own project, the ambient module declaration is still compatible and won't cause any issues.
102
+
110
103
  ## CLI reference
111
104
 
112
105
  ```
@@ -130,72 +123,7 @@ babelfhir-ts [options] [<input> [output]]
130
123
 
131
124
  - **Directory** – scan all `.tgz`, `.zip`, or `.json` files inside the folder
132
125
  - **Archive** – process a FHIR NPM package in `.tgz` or `.zip` format
133
- - **StructureDefinition JSON** – generate code for a single profile definition
134
-
135
- ## Generated output
136
-
137
- For each StructureDefinition the generator produces:
138
-
139
- - `*.ts` interface definitions (extending the canonical FHIR types)
140
- - `*Class.ts` companions that offer:
141
- - constructor helpers (`empty`, `random`, `randomClass`)
142
- - deterministic field filling for required and must-support elements
143
- - `validate()` that evaluates FHIR invariant expressions via `fhirpath`
144
- - optional validation parity artefacts when you run the test suite (`npm test validatorParity`)
145
-
146
- The validator relies on `fhirpath.evaluate(...)` to enforce profile invariants (including min cardinalities, slices, and custom expressions) without requiring a full FHIR server. It intentionally performs **high-level** checks only: terminology expansion, reference resolution, and other server-backed logic are out of scope, so keep a downstream validator (e.g. the HL7 Java validator CLI) in your QA pipeline for full conformance.
147
-
148
- ### Example: Generated US Core Encounter Profile
149
-
150
- Given the US Core Encounter profile, BabelFHIR-TS generates TypeScript interfaces that capture all must-support elements and profile extensions:
151
-
152
- ```typescript
153
- import { Encounter, Meta, Extension, Identifier, Coding, CodeableConcept,
154
- Reference, EncounterParticipant, Period, EncounterHospitalization,
155
- EncounterLocation } from "fhir/r4";
156
-
157
- // Extension interface with type-safe URL
158
- export interface UsCoreInterpreterNeeded extends Extension {
159
- url: 'http://hl7.org/fhir/us/core/StructureDefinition/us-core-interpreter-needed'
160
- }
161
-
162
- // Profile interface extending base Encounter with must-support constraints
163
- export interface USCoreEncounterProfile extends Encounter {
164
- /** Must Support */
165
- meta?: Meta;
166
- /** Must Support */
167
- identifier?: Identifier[];
168
- /** Must Support */
169
- class: Coding;
170
- /** Must Support */
171
- type: CodeableConcept[];
172
- /** Must Support */
173
- subject: Reference;
174
- /** Must Support */
175
- participant?: EncounterParticipant[];
176
- /** Must Support */
177
- period?: Period;
178
- /** Must Support */
179
- reasonCode?: CodeableConcept[];
180
- /** Must Support */
181
- reasonReference?: Reference[];
182
- /** Must Support */
183
- hospitalization?: EncounterHospitalization;
184
- /** Must Support */
185
- location?: EncounterLocation[];
186
- /** Must Support */
187
- serviceProvider?: Reference;
188
-
189
- // Typed extension slicing
190
- extension?: (Extension | UsCoreInterpreterNeeded)[];
191
- }
192
-
193
- // Generated validator function
194
- export async function validateUSCoreEncounterProfile(
195
- resource: USCoreEncounterProfile
196
- ): Promise<{ errors: string[], warnings: string[] }>;
197
-
198
- ```
126
+ - **StructureDefinition JSON** – generate code for a single profile definitio
199
127
 
200
128
  ## Scripts for contributors
201
129
 
@@ -210,6 +138,12 @@ export async function validateUSCoreEncounterProfile(
210
138
 
211
139
  The generator caches downloaded StructureDefinitions and packages inside `.cache/`. When you need a clean run, pass `--no-cache` or manually remove the folder. Temporary downloads land in `.temp-*` directories and are cleaned up automatically.
212
140
 
141
+ ## Why BabelFHIR-TS?
142
+
143
+ **The FHIR Challenge**: Implementation Guides define strict profiles that constrain base FHIR resources with required or must-support elements, custom extensions, value set bindings, and cardinality rules. Existing TypeScript libraries can't capture these requirements when you need profile-specific types, leading to an overhead when using TypeScript to build apps that interact with FHIR servers.
144
+
145
+ **The BabelFHIR-TS Solution**: Automatically generates TypeScript interfaces and validation logic directly from StructureDefinition JSON. Your IDE autocompletes required fields, flags missing extensions at compile-time, and validates FHIRPath invariants at runtime.
146
+
213
147
  ## Limitations
214
148
 
215
149
  BabelFHIR-TS is a code generation tool that parses FHIR StructureDefinitions and produces TypeScript interfaces and validators. While it handles many common FHIR profiling patterns, there are important limitations to be aware of:
@@ -243,6 +177,7 @@ BabelFHIR-TS is a code generation tool that parses FHIR StructureDefinitions and
243
177
  ### Reporting Issues
244
178
 
245
179
  If you encounter an Implementation Guide that doesn't generate correctly, please [open an issue](https://github.com/quotentiroler/BabelFHIR-ts/issues) with:
180
+
246
181
  - The package name and version
247
182
  - The specific StructureDefinition URL
248
183
  - Expected vs. actual generated output