Stream: tooling
Topic: NPM proposed changes
Grahame Grieve (Aug 24 2020 at 19:51):
@Martijn Harthoorn :
Martijn Harthoorn (Aug 28 2020 at 15:42):
That means that they are now going to be formally discussed before we can make these changes to the spec, right?
Martijn Harthoorn (Aug 28 2020 at 15:45):
Btw, I see that some packages have a dependency on a "current" version of another package. That has no meaning in our specification or in npm afaik.
Martijn Harthoorn (Aug 28 2020 at 15:46):
I know that your internal build system has a meaning for it, but these packages should probably not (yet) end up in the f eeds
Grahame Grieve (Aug 28 2020 at 22:10):
I see that some packages have a dependency on a "current" version of another package
That was such an obviously stupid thing to try to do that I never thought to add a check in the system to prevent it. So of course, it happened. I don't know what you should do with the ones already published because they're pretty much meaningless. It won't be happening any more
Oliver Egger (Aug 29 2020 at 10:23):
caught me ... we published our ch-core guide with a dependency current to ch-epr-term where we have terminologies defined which are regularly updated with patches or minor changes. but figured out too late that current has a different meaning. we would like to specify that our ch-core is depending on ch-epr-term but accept also patches or minor changes. for npm dependencies this can be specified e.g. >2.0.0, could such a construct also be used to handle ig dependencies?
Grahame Grieve (Aug 29 2020 at 20:28):
@Martijn Harthoorn I think we excluded any form of solution to this problem?
Martijn Harthoorn (Aug 31 2020 at 19:54):
We excluded npm ranges from the FHIR package spec, to prevent non experienced users shooting themselves in the foot.
From a technical perspective, I don't mind it. We did implement it in Simplifier and Torinox (just in case).
In the FHIR package spec, we did specify wildcards for patches to solve floating dependencies:
https://confluence.hl7.org/pages/viewpage.action?pageId=35718629#NPMPackageSpecification-Versionreferences
I wouldn't mind opening that up to minor updates as well.
Martijn Harthoorn (Aug 31 2020 at 19:54):
e.g. 2.x
Grahame Grieve (Aug 31 2020 at 20:05):
yes agree
Grahame Grieve (Sep 02 2020 at 02:01):
@Martijn Harthoorn I am adding a new entry into the packages that I generate:
"notForPublication": true
(in the package.json). This is added when the build is not building packages that are appropriate for distribution into the publication package system. They are built as part of ci-builds, local builds etc. You should not see them in any real distributed packages, and I would like it if the package server refuses to host such packages- thanks
Grahame Grieve (Sep 02 2020 at 02:01):
the field will not be added to packages intended for distribution / publication (e.g. I won't add it, rather than adding it with a value of false)
Ward Weistra (Sep 02 2020 at 15:23):
@Grahame Grieve Is there a benefit to adding them to the package feed at all then? Wouldn't it be easier to exclude them at that point already?
Grahame Grieve (Sep 02 2020 at 20:22):
indeed, I added rule about this at several levels, but I wanted to make sure that creative HL7 editors don't do an end run around the infrastructure, or there's no some path through the process that I've missed
Last updated: Apr 12 2022 at 19:14 UTC
