Hyvä 1.4.0 moved the default theme to Tailwind CSS v4. The practical consequences are that configuration moves out of tailwind.config.js and into your CSS, gradient utilities are renamed, and cascade layers change how your custom overrides win or lose. Tailwind’s codemod handles most of it. Your child theme’s custom CSS is the part that needs eyes.
If you are on a Hyvä 1.3 theme and have been deferring this, the upgrade is worth understanding before you schedule it. It is not a routine patch bump, and it is also not a rebuild. Here is what actually changed and how to size the job.
What landed in 1.4
From the Hyvä default theme changelog, version 1.4.0 shipped on 10 November 2025 with several changes that matter beyond the Tailwind bump:
- Tailwind CSS v4. The headline change, and the source of most upgrade effort.
- Design tokens. A named token system replacing older colour values, giving clearer semantics than the previous
fgnaming. - The reset-theme dependency was removed. One less module in the chain.
- HTML
dialogelements in the mobile menu header and minicart, replacing custom implementations with the native element. - View transitions stabilised as production-ready rather than experimental.
- Header rework that removed most of the CSS order logic in favour of native browser ordering, fixing a set of UX and accessibility issues.
The point releases since are smaller and mostly worth taking. 1.4.1 fixed view transitions between product pages and improved address field validation. 1.4.2 added an input-group CSS component for bundling form fields. 1.4.3 improved PayPal button initialisation and fixed wishlist rendering. 1.4.4 extended the design token system, added a Cmd or Ctrl plus K keyboard shortcut for search, and improved gallery performance.
Worth noting alongside this: the licence change to dual OSL and AFL landed from 1.3.21, so if you are on a recent 1.3 you are already on the open-source licence and the 1.4 decision is purely technical.
What Tailwind v4 actually changes
Three changes account for nearly all the work.
Configuration moved from JavaScript into CSS. In v3, tailwind.config.js was where theme values, plugins, and dark mode strategy lived. In v4, your CSS file is the configuration. Design tokens, theme values, and plugin imports are declared in CSS using native custom properties and the @theme directive. For a Hyvä child theme with a customised config, this is the single biggest translation task.
Gradient utilities were renamed. Every bg-gradient-to-* becomes bg-linear-to-*, following CSS-native linear-gradient naming. This is mechanical, widespread, and the codemod catches it.
Cascade layers changed specificity. Tailwind v4 uses native CSS cascade layers (@layer theme, base, components, utilities). If your custom CSS relied on v3’s specificity behaviour to override something, those overrides may now land differently. This is the change that produces the confusing bugs, because nothing errors. Styles simply apply in an order you did not expect.
Plugin format also changed, with plugins imported directly rather than required in a config file.
The engine underneath is new too. Tailwind v4 ships the Oxide engine, a Rust rewrite that uses Lightning CSS for parsing rather than the PostCSS pipeline, described in Tailwind’s v4 announcement. The visible effect for your team is faster builds, which is welcome but is not a reason to upgrade on its own.
Tailwind provides an automated codemod, npx @tailwindcss/upgrade, documented in the official upgrade guide, which handles a large majority of the mechanical changes. Treat it as doing the boring 90%, not the whole job.
One caution specific to Magento. The upgrade guide assumes a fairly standard project layout, whereas a Hyvä child theme sits inside a Magento module structure with its own build entry point. The codemod will find and rewrite your utility classes, but you should expect to point it at the right paths rather than run it blind at the project root, and to review what it touched before committing.
Scoping the upgrade honestly
The variable that decides effort is not your Magento version. It is how much custom CSS your child theme carries and how much of it fought the framework.
| Child theme profile | Typical effort | Where the time goes |
|---|---|---|
| Close to stock, few overrides, Tailwind utilities used as intended | Low | Run the codemod, translate config, visual QA |
| Moderate customisation, some custom components and a modified config | Medium | Config translation, specificity fixes, component retest |
| Heavy custom CSS, many template overrides, specificity workarounds | High | Untangling overrides that no longer win under cascade layers |
| Custom Tailwind plugins | Add to any of the above | Plugin format rewrite |
This is the practical argument for the discipline everyone recommends and few follow. Teams that kept their child theme close to the default and used Tailwind utilities rather than fighting them get through this upgrade quickly. Teams that accumulated specificity hacks pay for them here. It is the same principle we set out in our guide to what Hyvä theme development actually involves: the cheapest theme to maintain is the one that overrides least.
A sequence that avoids surprises
Take an inventory first. Before running anything, list your custom CSS files, any custom Tailwind plugins, your config modifications, and every template override in the child theme. This inventory is your test plan later.
Run the codemod on a branch. npx @tailwindcss/upgrade will handle the gradient renames and much of the mechanical work. Commit that separately so the automated changes are reviewable in isolation from your manual ones.
Translate the config deliberately. Move theme values, tokens, and plugin registrations from tailwind.config.js into CSS with @theme. Do this by hand and read it, rather than pattern-matching. This is where a subtle mistake produces colours or spacing that are almost right, which is worse than obviously wrong.
Hunt the specificity regressions. Walk your inventory of custom CSS and check each override still applies. Cascade layers are the silent failure mode of this upgrade. Prioritise anything that styles a component you also override in a template.
Retest the reworked areas. The header, mobile menu, and minicart all changed in 1.4, and the header rework in particular removed CSS ordering logic. If you customised any of those, they need real testing rather than a glance.
Check third-party Hyvä modules. Any compatibility module or Hyvä-specific extension needs a version that supports 1.4. This follows the same triage we describe in adapting third-party Magento extensions to Hyvä.
Build on staging, measure, then ship. Confirm the Tailwind build runs in your pipeline, then check Core Web Vitals did not regress before and after. Where the build belongs is covered in the Magento and Hyvä release pipeline guide.
What this costs you if you skip it
Deferring has a compounding price that is easy to miss because nothing breaks on the day you decide to wait.
Every sprint you spend building against the v3 configuration model adds code you will translate later. Custom components written with v3 specificity assumptions are the expensive kind, because each one is a manual check during the eventual upgrade rather than something the codemod resolves. A team shipping frontend work continuously can add more upgrade debt in six months than the upgrade itself would have cost today.
There is also a support dimension. Fixes and improvements land on the current line, so a store on 1.3 gradually stops receiving the accessibility, performance, and component work that 1.4 point releases have been accumulating. The gallery performance work and the header accessibility fixes are both examples of improvements you simply do not get by staying put.
None of that makes it urgent. It does mean the calculation is not “upgrade now versus upgrade later at the same price.” Later is usually more expensive, and the gap widens with how actively you develop.
Should you upgrade now?
Our honest position is that this is a “yes, but schedule it properly” upgrade rather than an emergency.
Reasons to move sooner: you are already planning frontend work and can fold this in; your child theme is close to stock so the cost is genuinely low; you want the accessibility and UX fixes in the header rework; or you are about to start a significant build and would rather start on 1.4 than migrate later with more custom code to carry.
Reasons to wait: you are mid-way through another large project and cannot absorb a frontend regression cycle; your child theme is heavily customised and you want to reduce override debt first, which is worth doing anyway; or you are on an older Magento patch level and have a platform upgrade to sequence ahead of it.
What we would not do is skip 1.4 indefinitely. Point releases and fixes accumulate on the current line, and the longer you stay on 1.3 the more custom code you write against a config model that is going away.
How Bemeir helps
Bemeir is a Brooklyn ecommerce agency and the USA’s first official Hyvä Gold Partner, with a direct line to the Hyvä team since the project started. We have done this upgrade on themes at both ends of the customisation spectrum, which is why the estimate we give starts with reading your child theme rather than quoting a standard number.
Our Hyvä development services cover the upgrade, the override cleanup that makes future upgrades cheaper, and the build pipeline work. That sits inside a wider Magento and Adobe Commerce development practice, so if a platform upgrade needs to come first we will sequence it that way. We also build on Shopify and Shopify Plus, Shopware, and BigCommerce, and module compatibility questions draw on our technology partner ecosystem.
More about the team is on the about Bemeir page, or start a conversation from the Bemeir homepage.
Frequently asked questions
What version of Tailwind does Hyvä 1.4 use?
Tailwind CSS v4. Hyvä 1.4.0, released on 10 November 2025, updated the default theme from Tailwind v3 to v4, which brings the Rust-based Oxide engine, CSS-first configuration, and a set of breaking changes to utility names and cascade behaviour. Hyvä 1.3 themes remain on Tailwind v3.
Will the Tailwind upgrade tool do the whole Hyvä 1.4 migration?
No. The npx @tailwindcss/upgrade codemod handles roughly the mechanical majority, including the bg-gradient-to-* to bg-linear-to-* renames. What it cannot do for you is translate a customised tailwind.config.js into CSS-based configuration with real judgement, or find custom overrides that stopped winning because cascade layers changed specificity. Budget manual time for both.
What is the riskiest part of moving from Hyvä 1.3 to 1.4?
Cascade layers. Tailwind v4 uses native CSS layers, so custom CSS that relied on v3 specificity behaviour can silently apply in a different order. Nothing throws an error, the page simply looks subtly wrong, which makes it easy to miss in a quick visual check. Inventory your custom CSS before upgrading and test each override deliberately.
Do I need to upgrade to Hyvä 1.4 to get the open-source licence?
No. The dual OSL and AFL licensing was adopted from version 1.3.21, so a recent 1.3 theme is already on the open-source licence. That makes the 1.4 decision purely technical rather than commercial, and you can schedule it around your roadmap rather than treating it as urgent.
What else changed in 1.4 besides Tailwind?
Several things worth testing if you customised them. Design tokens replaced older colour naming, the reset-theme module dependency was removed, native HTML dialog elements replaced custom implementations in the mobile menu header and minicart, view transitions became production-ready, and the header was reworked to use native browser ordering instead of CSS order logic, which fixed a number of UX and accessibility issues.
