search

zwilias / elm-json

Install, upgrade and uninstall Elm dependencies
MIT License
182 stars 9 forks source link

Suggestion: Indicate why a package is not updated to the latest version #48

Open jfmengels opened 1 year ago

jfmengels commented 1 year ago

A problem that can be quite opaque to the user when using elm-json to upgrade dependencies, is when you don't get the latest version.

For instance, if you're using jfmengels/elm-review v2.9.0 and elm-explorations/test v1, then attempting to upgrade the latest will only yield the v2.9.1 version, because starting from v2.10.0, the package depends on elm-explorations/test v2.

I have seen a lot of confusion as to why people were not getting the most recent version, and I myself get confused in different situations, in which case I resort to this tool (https://www.markuslaire.com/github/elm-dependencies-analyzer/) to figure out the problem.

I think it could be interesting to explain — when upgrading to not the last version — why the upgrade was held back to a prior version.

I think that this could be challenging to explain in a clear way, but it could be worth it. A first stab could look like this:

npx elm-json install jfmengels/elm-review@2 -- PACKAGE CHANGES READY -------------------------------------------------------

I want to make some changes to your direct dependencies

  • [CHG] jfmengels/elm-review 2.6.2 -> 2.9.1

A newer version of jfmengels/elm-review (2.10.0) exists, but it depends on

  • elm-explorations/test 2.0.1 <= v < 3.0.0 while you're depending on
  • elm-explorations/test v1.0.0

To upgrade to the latest version, you could upgrade all of these, by running

Should I make these changes anyway?

(cc @mpizenberg who might also be interested in this kind of issue)

mpizenberg commented 1 year ago

So one way to implement something like this for a command like elm-json install author/pkg@requirement would be to have the following strategy:

  1. Identify the newest version of author/pkg satisfying the requirement
  2. Try to solve with that specific version
  3. If that fails, record the error message and try again with the actual requirement
  4. If it succeeds with the actual requirement but failed with the newest version satisfying that requirement, add a warning containing the error message for the newest version