Stream: shorthand
Topic: load package resolution
Brian Kaney (Jun 25 2020 at 14:11):
Hi all -- I was looking at load.ts and all the sushi conventions baked in. We have a use-case where we want to use alternative npm registries for our FHIR packages, and might want to support npm -conventions to specify this (--registry
)
Grahame Grieve (Jun 25 2020 at 21:53):
out of interest, what's the use case?
Brian Kaney (Jun 25 2020 at 21:54):
We have several private packages / IGs we publish to an internal NPM registry.
Chris Moesel (Jun 25 2020 at 22:44):
Does the IG Publisher support this? Because if we added support in SUSHI, you might still be stuck on the IG Publisher. (Although maybe not, because if SUSHI puts it in the fhir .cache, maybe the publisher wouldn't try to find it elsewhere anyway?)
Grahame Grieve (Jun 25 2020 at 23:43):
the IG publisher won't look for it anywhere else if it's in the cache. But I asked about the use case because I figured it would propagate into the validator and publisher. Which it sounds like it will
Grahame Grieve (Jun 25 2020 at 23:44):
if you put a test package in a public server that expresses the same API, then I'll make sure it works and figure out what the configuration would look like
Matt Rouhana (Nov 24 2021 at 18:29):
@Grahame Grieve and/or @Chris Moesel - did anything ever come of this thread? I have a similar use case as @Brian Kaney.
Grahame Grieve (Nov 24 2021 at 18:44):
no because there was no test case
Chris Moesel (Nov 24 2021 at 21:55):
Nothing on our end either. I’m hesitant to support loading packages that the IG Publisher doesn’t support loading itself…
Patrick Werner (Nov 25 2021 at 12:29):
@Brian Kaney @Matt Rouhana
i ended up loading the file from our internal NPM via wget and then using firely terminal to create snapshots via fhir bake
(currently broken, will be fixed soon), and the installed the package with fhir install
Patrick Werner (Nov 25 2021 at 12:29):
`
Brian Kaney (Nov 25 2021 at 13:49):
@Matt Rouhana For publishing, we take the generated fhir package and publish to an internal npm repo (artifactory). Then we ended up writing a wrapper script that reads sushi-config.yaml (dependencies) and directly manipulates ~/.fhir/packages
to install private packages before running sushi/publisher - We do this for both local development and in our CI/CD pipeline.
Matt Rouhana (Nov 25 2021 at 16:54):
@Brian Kaney - thanks, that's the design I was thinking about as well.
Last updated: Apr 12 2022 at 19:14 UTC