43 multiple changes r4 - Githubissues

smilecdr / FHIR.ts

TypeScript/JavaScript FHIR Library

https://www.npmjs.com/package/@smile-cdr/fhirts

Apache License 2.0

37 stars 10 forks source link

43 multiple changes r4 #44

Closed TahaAttari closed 1 year ago

TahaAttari commented 1 year ago

Added a ResourceList type for codes which are part of the ResourceTypes codesystem
Updated Required status for: MessageDefinition.focus.code, CapabilityStatement.rest.resource.type, GraphDefinition.start, GraphDefinition.link.target.type, ImplementationGuide.global.type, SearchParameter.base, SearchParameter.target, OperationDefinition.resource, CompartmentDefinition.resource.code, ExampleScenario.instance.resourceType
Changed BundleEntry.resource and other uses of generic Resource to a union type which supports inference and narrowing.

Closes #43

changeset-bot[bot] commented 1 year ago

⚠️ No Changeset found

Latest commit: e6be9ca6e1334f8457343f49eb10c1a2f33b20ae

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

omarhoblos commented 1 year ago

@TahaAttari since this introduces a huge change to R4, it would be good to update the GETTINGSTARTED.md file with the latest changes to how R4/ STU3 work in this library. I think it'd be best to separate them into two categories::

First half has changes before this update - this keeps the original documentation as is Second half has changes starting from this update - this would basically follow the same structure as the first half, but show the syntax changes an implementer would expect.

I think it's also fair to flag the changes as Breaking Changes because of how significant the uplift is compared to previous version - if anything this warrants a full version bump to 2.0

TahaAttari commented 1 year ago

It should be a drop-in change and not break any code which is spec-compliant. I'm happy to add to GETTINGSTARTED.md but that would be more about the utility/pitfalls of type narrowing since that's the major addition.