Adding upper bounds to dependencies is generally considered a bad practice, as most of the time new "major" versions will not introduce any breaking changes. A couple reasons to not add these upper bounds:
each time a new "major" version is out, dependencies need to be updated. I see this is already being handled, but might not be in the future if the project lacks maintenance for some time.
If this isn't handled, users of djlint are bound to versions they don't control. Say I want to use a feature in html-tag-names>=0.2.0 inside my virtualenv where djlint is installed, I'd have to open a PR on this repo to loosen the dependency on html-tag-names (which currently is >=0.1.2,<0.2.0), and there're probably no breaking changes for this version bump.
Feature Request
Adding upper bounds to dependencies is generally considered a bad practice, as most of the time new "major" versions will not introduce any breaking changes. A couple reasons to not add these upper bounds:
djlint
are bound to versions they don't control. Say I want to use a feature inhtml-tag-names>=0.2.0
inside my virtualenv wheredjlint
is installed, I'd have to open a PR on this repo to loosen the dependency onhtml-tag-names
(which currently is>=0.1.2,<0.2.0
), and there're probably no breaking changes for this version bump.This lengthy article goes into more details.
If you are ok with this, I can open a PR.