Hyva Module Compatibility: Which Magento Extensions Still Work?

Hyva removes Knockout, RequireJS, and jQuery from the storefront. Most Magento 2 extensions assume those are present, so a third-party module that adds a "size guide" popup using a sprinkle of jQuery has nothing to plug into on Hyva.

To bridge the gap, Hyva runs a system called the Hyva Compatibility Module Tracker (hosted at gitlab.hyva.io/hyva-public/module-tracker): a catalogue of compatibility modules, vendor-shipped Hyva-native versions and community contributions that re-implement the frontend of popular Magento 2 extensions in Alpine.js and Tailwind. The backend module (its database, admin, API) stays the same. Only the storefront frontend gets re-implemented.

How compatibility works in practice

Three categories cover almost every module on your store:

Backend-only modules. These don't touch the storefront frontend at all. Inventory management, admin tools, order workflow modules, shipping rate calculators. They work on Hyva without any change. The majority of installed extensions on a mature Magento store fall into this category.

Frontend modules with Hyva compatibility. Module vendors increasingly ship Hyva-native versions alongside their Luma versions, or the Hyva Module Library has an official compatibility connector. You install the compatibility module alongside the original, and the frontend uses the Hyva-native version automatically.

Frontend modules without Hyva compatibility. No Hyva-native version, no Module Library connector. You have four options: build a compatibility module in-house (a few days of senior dev time), replace the module with a Hyva-compatible alternative, remove the feature entirely, or wait for the vendor to ship Hyva support.

The status of major Magento extension vendors

Approximate state of Hyva compatibility for the most-used commercial extension vendors as of 2026. This moves quickly, so verify the specific extension you care about on hyva.io's module library directly.

The picture has improved steadily over the years. Five years ago, Hyva compatibility for major vendors was a coin-flip. Today, most established vendors either ship Hyva versions natively or have community compatibility modules in the Module Library.

How to run the audit yourself

Don't outsource this. Sit down with your team and do the audit before you brief agencies, because the result drives the budget.

1. On production, run bin/magento module:status and copy the output.
2. Filter to the vendor and custom modules. You can ignore everything starting with Magento_, those are core and Hyva supports them all.
3. For each remaining module, search the Hyva Module Library at hyva.io. Note the status: native Hyva version, compatibility module available, or nothing exists.
4. For your in-house custom modules, walk the codebase. Anything that includes .phtml templates extending Luma blocks, any requirejs-config.js, any Knockout view-model HTML attribute — those need porting.

Build a spreadsheet with columns: module name, vendor, current usage (in use / probably unused / unused), Hyva status, estimated rework time. Share it with agencies you're briefing. The conversation gets immediately sharper.

What to do with modules that have no Hyva support

Four options, in rough order of cost:

Remove the feature. Genuinely consider this. A surprising number of installed extensions are doing work that nobody currently uses, was installed for a campaign two years ago, or could be done with a much simpler solution. Removing a feature is free and reduces complexity.

Replace with a Hyva-compatible alternative. Often there's a comparable module from a different vendor that does have Hyva support. Switching costs you the licence of the replacement and a few hours of configuration, but no custom development.

Build a bespoke compatibility module. A few days to a few weeks of senior developer time depending on the module's complexity. The result is your-store-specific and your team has to maintain it, but it preserves the exact feature behaviour you have today.

Wait. Sometimes the vendor's roadmap genuinely has Hyva support coming. If the feature is non-critical and the wait is short, defer the migration on that store view or that feature only. We've seen merchants wait three to six months for vendor support and skip the bespoke work entirely.

Modules that need the most care

Three categories deserve extra attention in the audit:

Checkout-related modules. Custom checkout fields, shipping method modifications, payment method UI customisations. These are the highest-impact place to get compatibility wrong, because checkout regressions hit conversion directly.

Tracking and analytics modules. Anything that fires events on cart, mini-cart, checkout, or purchase. Luma fires these through Knockout view models. Hyva fires them through Alpine event triggers. The implementation is different and your data layer pushes need re-wiring.

Promotional / cart price rule modules. Cart-page popups, banner injection, dynamic promotions that read cart state. These typically need re-implementing in Alpine even if the backend logic is unchanged.

If you've already started the migration without doing the audit

You're not the first. The recovery move is:

1. Stop active development and run the audit now, even if it means losing a week.
2. Reassess scope and budget with what you find.
3. Renegotiate the project plan with your agency on the basis of the new module map.

It's painful but it's far cheaper than discovering three load-bearing module incompatibilities in week 8 and trying to recover the project on the back foot.