andershol
commented
5 years ago It seems that if I put a specific version (i.e. "1.5.4") of a "sub package" (say, "polythene-core-button") explicitly in my apps packages.json, that version will be used. But there are 99 of them and it seems kind of fragile to maintain a list of them so I'd rather not need to do that. But that will make it work for now. But I guess that also mean that you could make "cyano-mithril" and "mithril-hooks" depend on "1.1.6 || 2.0.0-rc.6" (assuming that you don't really need 2.x). ... And a bit unrelated, you could perhaps use it as a hack to switch between react and mithril by having cyano 1.1.x use mithril and 1.2.x use reach and let the users choose the frameworks via the filters. Then I guess you wouldn't need "polythene-mithril-" / "polythene-react-" packages (if all their differences have been abstracted into cyano). (You obviously have spend more time working on this, so I hope I'm not stating the obviously stupid).
ArthurClemens
The npm packages currently use "^" in the version when referring to dependencies. E.g. the "polythene-mithril" version 1.5.4 package declares a dependency on "polythene-mithril-button" version "^1.5.4" and that means any "1.x" version, currently including "1.6.4".
Version polythene 1.6.x takes a dependency on mithril 2.0.0-rc.6, (via cyano-mithril). I'd really like to stay on mithril 1.x for now as 2.x breaks some features (and it is still a "rc"). But after I updated my npm packages I can't go back and get polythene version 1.5.4 as that will fetch "1.6.4" of all the sub-packages. There are probably a way for me to pin a package, but there are a lot of polythene packages, so it seems daunting and I currently don't know how.
So I think you should switch to using exact versions (not "^" nor "~") in dependencies at least when referring to your own packages, but I am not familiar with npm best practices in this regard. Right now it seems to me that I would need a 1.5.5 with exact versions for my project to just work again.