As I havn’t yet seen any solution for solving elm.json dependency conflicts, I decided to try creating a small app for this, while waiting for someone else to come up with a proper solution. This is my first Elm app of over 1000 lines, so probably full of bugs.
The app parses given elm.json, then loads information about related packages and their versions, and shows a table of the versions of elm.json and all newer versions, including all indirect packages.
There is no automatic conflict resolution, but user can select versions from table and any dependency conflicts will be listed below. There is also some color coding to help select versions.
I havn’t written any manual/help yet, so here are few notes about how this (currently) works:
Open/paste your elm.json or click “Load Example” to see an example with some conflicts
Press Analyze to parse JSON and load package information (this can take a moment)
selected versions have blue background
versions which are incompatible with selected versions have red background
when hovering cursor over any version, all versions incompatible with that one have red border
selected versions can be changed by clicking another version
checkboxes change which packages are considered direct packages
when removing direct packages, any indirect packages which aren’t needed anymore will be marked with strikethrough
if selected versions have conflicts, those are listed below the table
Example image:
the selected versions (blue background) don’t have any conflicts here
three newer versions are incompatible with selected versions
(elm/http 2.0.0 ; krisajenkins/remotedata 6.0.0 and 6.0.1)
mouse pointer is over krisajenkins/remotedata 6.0.1 which is incompatible with 7 versions, shown with red border
ps. All HTTP requests go to my php backend which enforces 24 hour caching. So while this app does make quite many requests, they should be cached quite nicely, and don’t cause much load to package.elm-lang.org
Cool indeed! Seems to me it would be useful to have an export/download feature as well - you could play around with choosing different versions and then once you’re happy with it, download an updated elm.json.
First I need to decide how to handle test-dependencies which I don’t include yet. I’m thinking adding another yes/no selector for each package so packages can be moved between direct/indirect/direct-test/indirect-test.
After that I just need to add ability to add new packages and this could be used to generate elm.json from scratch.
Nice, I only searched if there was anything for determining package compatibility which is the hardest part (doesn’t seem to be), so I missed that.
Especially when adding download/export it’ll be good to use official decoder/encoder to make sure nothing is lost in conversion.
Still the Version and Constraint types there are opaque which doesn’t work well with compatibility-calculations, so I’ll probably still use my own instead of those. Also Constraint doesn’t seem to have any way of getting min/max version, so I’m not sure if I can actually use that at all.
(EDIT: I just created an issue about this.)
Which might be easy, I only looked at doing an implementation for elixir, which unfortunately isn’t very nice to parse, and thus I did stop working on it.
Awesome indeed. @malaire pointed me to this today when I was haviing weird dependency problems – got an instant diagnosis. A really valuable contribution to the ecosystem.
I agree, thanks for making it. The versioning in 0.19 got more difficult I think, because of locked down dependencies for applications. Your tools at least tells me what possible upgrade paths could look like. Thanks. I’ll be using it much.
