htmx 4.0 has shipped, but upgrading isn't as simple as changing a version number.
The htmx team is keeping npm's latest tag on 2.0.10 while 4.0.0 sits under next. That gives applications using unversioned CDN URLs and package ranges time to migrate without an unexpected runtime change.
If you're considering htmx 4, start with these differences:
- Error responses behave differently
htmx 4 swaps HTTP responses by default except 204 and 304. That means a 422 validation response can now be swapped naturally—but an unexpected 500 HTML page could also end up inside your target.
- hx-disable changed meaning
This is an easy migration trap.
hx-disable → don't process this element.
hx-ignore → don't process this element.
hx-disable → disable elements while a request is running.
Old markup can therefore remain valid HTML while doing something completely different.
- Attribute inheritance is explicit
Attributes that previously inherited from parents now require the :inherited suffix.
For example:
hx-confirm:inherited
There is also a compatibility setting to temporarily restore the old behavior.
- Requests now have a 60-second default timeout
Applications with long-running requests need to review this setting rather than assuming the old indefinite behavior.
- More migration details matter
Also check:
hx-delete form input behavior
OOB swap ordering
hx-ext
renamed events
removed hx-vars, hx-params, hx-prompt, and hx-request
history behavior
extensions
morph swaps
The official migration checker helps with the mechanical changes:
npx htmx.org@4.0.0 upgrade-check -- ./templates
But static checks aren't enough. Runtime behavior still needs application-level testing.
The safest migration strategy is simple: pin htmx 4.0, run the checker, then test the edge cases your application actually depends on.
Full article:
https://blog.invidelabs.com/htmx-4-npm-default/
Top comments (0)