FHIR Chat · Generate package.json with sushi · shorthand

Stream: shorthand

Topic: Generate package.json with sushi


view this post on Zulip Ward Weistra (Jan 20 2022 at 22:21):

@Chris Moesel Hi! Is there an option for sushi to generate/update a package.json based on the contents of sushi-config.yaml (or the other way around)? I don't have an IG resource in https://github.com/FirelyTeam/ACME-FSH-Example and Firely Terminal needs a package.json for knowing the project details.

view this post on Zulip Elliot Silver (Jan 20 2022 at 22:47):

I think package.json is generated by IG publisher. I haven't found a way to influence its contents yet.

view this post on Zulip Chris Moesel (Jan 20 2022 at 23:35):

Right, as @Elliot Silver noted, we rely on the IG Publisher to generate the package.json. We don't manipulate it ourselves.

We could potentially look into doing this, but I'm not sure how it jives with the publisher workflow. I wouldn't want to create a package.json that causes trouble/conflicts with the IG Publisher, so it would probably need to be an option of some sort.

view this post on Zulip Elliot Silver (Jan 20 2022 at 23:37):

I think it may actually be the templates/jekyll processing that create it, but that's beyond my limit.

view this post on Zulip John Moehrke (Jan 21 2022 at 00:00):

package.json is a file that is created by the publishing process. manually... and usually checked into your project.

view this post on Zulip Jose Costa Teixeira (Jan 21 2022 at 07:52):

which package.json is this about? I only see one, inside package.tgz, and that one is generated by the publisher.

view this post on Zulip Hank Lenzi (Jan 21 2022 at 11:55):

Elliot Silver said:

I think it may actually be the templates/jekyll processing that create it, but that's beyond my limit.

in ../org.hl7.fhir.publisher.core/src/main/java/org/hl7/fhir/igtools

The Java code is divided into publishers/renderers/spreadsheet/teplates/ui

Beyond my limit/lifespan too (this is a large code base and the whole thing is not well documented, with even some document drift)

view this post on Zulip Ward Weistra (Jan 21 2022 at 23:09):

Thanks for all the input!

@Chris Moesel In my testing the IG Publisher just ignores any package.json present in the root. And the only one it outputs, as @Jose Costa Teixeira mentions, is in .\output\package.tgz (and some limited version at .\output\package.manifest.json).

view this post on Zulip Chris Moesel (Jan 21 2022 at 23:27):

Thanks for the info, @Ward Weistra. If the IG Publisher ignores a user-provided package.json then that means we can't mess it up -- but I could also see users being confused by seeing a package.json generated by SUSHI that is not used by the IG Publisher (and perhaps wondering why the one in their package.tgz is so different than the one that SUSHI generated). So I think I'd still want to make its generation be an opt-in sort of deal.

Could you provide some requirements regarding what you would expect a SUSHI-generated package.json to contain? And perhaps file an official issue requesting it over at https://github.com/FHIR/sushi/issues ?

view this post on Zulip Jose Costa Teixeira (Jan 21 2022 at 23:29):

Where would that package.json be? In which folder? Is there a risk it messes up the publisher itself?

view this post on Zulip Ward Weistra (Jan 21 2022 at 23:30):

@Chris Moesel Will create a feature request and provide more details there!

view this post on Zulip Ward Weistra (Jan 21 2022 at 23:34):

@Jose Costa Teixeira In the root folder, where the input and fsh-generated folder also live.
And regarding messing up the IG publisher: As stated above, I believe it completely ignores it. But let me know if you find differently.
And I totally see Chris' point on making it optional, so even if the publisher would look at it, it would be a deliberate user choice to turn that on.

view this post on Zulip Jose Costa Teixeira (Jan 21 2022 at 23:35):

I see. I never saw that file so i was wondering if it's going to be in input or any of the defined folders. If it's in the root it should be harmless

view this post on Zulip Ward Weistra (Jan 21 2022 at 23:38):

Firely Terminal, Simplifier and Forge use that package.json to know what dependencies a project needs and download and install these FHIR packages if needed. You can read more on the file here: https://confluence.hl7.org/display/FHIR/NPM+Package+Specification#NPMPackageSpecification-Packagemanifest

view this post on Zulip Elliot Silver (Jan 21 2022 at 23:41):

I'm confused about the use case. Is it so that someone using Sushi can upload their project to Simplifier, and include an already filled out package.json? Is it to provide more control over the publisher generated package.json?

view this post on Zulip Ward Weistra (Jan 21 2022 at 23:50):

@Elliot Silver The first one.

Take https://github.com/FirelyTeam/ACME-FSH-Example/, where I am using FSH to define my resources and Simplifier to create the Implementation Guide.
Currently I must manually bring over the package dependencies from sushi-config.yaml to a package.json. Otherwise, Simplifier is unaware of the package dependencies I already previously specified.
Similarly when I want to run Firely Terminal locally after my sushi run, to validate if the JSON output is correct or validate my custom business rules.

view this post on Zulip Elliot Silver (Jan 21 2022 at 23:51):

Aren't the dependencies in the IG resource though?

view this post on Zulip Elliot Silver (Jan 21 2022 at 23:52):

I suppose though, there are some projects that are missing IG resources (ahem, DICOM vocab).

view this post on Zulip Ward Weistra (Jan 21 2022 at 23:59):

@Elliot Silver Yes, sushi indeed brings them to the IG resource. Alternatively, we should teach our toolstack to search a full folder structure for (hopefully one) IG resource. But I'd strongly prefer to just have a package.json in the root of a FHIR development project and use the package infrastructure for this.
Just like with published FHIR packages, which also contain both the IG resource (or two...) and always exactly one package manifest (package.json).

view this post on Zulip Elliot Silver (Jan 22 2022 at 00:04):

Got it. OK. Or teach Simplifier to populate projects off of the package. (I suspect the number of people using Sushi who wouldn't be comfortable running the publisher once is limited.)

view this post on Zulip Ward Weistra (Jan 22 2022 at 00:11):

@Elliot Silver Simplifier will already happily accept a package.tgz if you upload that to your FHIR project :smile:
But I don't think that's the most efficient workflow.

view this post on Zulip Elliot Silver (Jan 22 2022 at 00:12):

Well, that would have saved me some time. :rolling_eyes:

view this post on Zulip Ward Weistra (Jan 22 2022 at 00:34):

Reported the feature request here: https://github.com/FHIR/sushi/issues/1010 :thank_you:

view this post on Zulip Chris Moesel (Jan 24 2022 at 14:22):

Thanks for the detailed writeup, @Ward Weistra. I've added a few of my thoughts in comments to that issue (for you or anyone else following along).


Last updated: Apr 12 2022 at 19:14 UTC