No Overly Restrictive Dependency Versions

[sparksp]

What the rule should do:

Check for overly restrictive versions in package dependencies. Generalised rule:

For "elm-version" (while major version is 0):

• Lower version's patch is 0
• Upper version is 0.(lower minor + 1).0

For "dependencies":

• Upper version is any.0.0
• The elm compiler will complain if upper <= lower

What problems does it solve:

This allows packages to be used with the best range of dependencies, and provides a sanity check on dependencies you've hand edited.

Example of things the rule would report:

"elm-version": "0.19.1 <= v < 0.20.0"

Nothing changed in 0.19.1 so this should be 0.19.0 <= v < 0.20.0. This also looks nicer when it's reported in the Slack #packages channel as "0.19" instead of a range.

"jfmengels/elm-review": "2.0.0 <= v < 2.2.0"

There should be nothing that prevents a user from using this with 2.2.0 or beyond so this should be 2.0.0 <= v < 3.0.0. Applications can avoid broken packages in elm.json (direct or indirect).

"jfmengels/elm-review": "2.1.0 <= v < 3.1.0"

If a package works with 3.0.0 then it should work with any 3.x.x so this should be 2.1.0 <= v < 4.0.0.

Example of things the rule would not report:

• "elm-version": "0.19.0 <= v < 0.20.0"
• "jfmengels/elm-review": "2.0.0 <= v < 3.0.0"
• "stil4m/elm-syntax": "7.1.0 <= v < 9.0.0"

Example Error Message

Overly restrictive version constraint for 'jfmengels/elm-review'

Elm checks that all package APIs follow semantic versioning, so it is best to use wide constraints. I recommend "2.2.0 <= v < 3.0.0" since it is guaranteed that breaking API changes cannot happen in any of the versions in that range.

When (not) to enable this rule:

• It's pointless for applications.

I am looking for:

• Sanity check:
  • Do the assumptions I've made about versioning make sense?
  • Can you think of genuine times when this rule would not work?
  • Is there a time when a package would want to depend on a patch version? Yes
• Someone to implement it with/for me
• Whilst I don't expect anyone would search out this rule, if it were part of a suite of cheap package rules it could be useful.

[sparksp]

It turns out that patches can be important as they can change the behaviour of a dependency that you might have relied upon or built a workaround for.