FHIR / FHIR/sushi

Consider issuing a warning (instead of an error) when constraining a type that is not a formal subtype

Open
#1,289 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
TypeScript
Stars
188
Forks
64
Avg merge
8d 11h
Merged PRs (30d)
3

Description

SUSHI currently only allows authors to constrain a type to a formal subtype of the resource or profile type. However, it is possible that a type could be constrained to another type that does conform to the type but is not a _formal_ subtype. SUSHI should consider loosening this error to a warning. There is a chance that someone used the wrong type and did make a mistake. However, it is possible the author knows the type they are trying to constrain to does actually conform to the base type.

SUSHI may be able to check that the base resource type of the original type and the constrained type match. If they don't match, then SUSHI knows the constraint is not valid. If they do match, SUSHI can't truly tell if the constrained type is allowed and should consider logging a warning saying so.

Zulip thread where this came up: https://chat.fhir.org/#narrow/stream/215610-shorthand/topic/Question.20about.20inheriting.20profiles
A simple FSH Online example that demonstrates the error SUSHI currently logs: https://fshschool.org/FSHOnline/#/share/3J4LxPR

Contributor guide

Open the contributing guide

Research direction

Start by reproducing the error with the linked FSH Online example, then locate the SUSHI validation that rejects constraints on non-formal subtypes. Define the behavior for matching versus mismatched base resource types; done means valid-looking cases produce a warning while mismatched cases remain errors.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
cli, compilers
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.