Tailwind CSS v4.2: webpack plugin, new colors, logical utilities

Tailwind v4.2.0 is the kind of release that feels small until you actually open the changelog. It lands tooling, design-token, and writing-mode upgrades that matter if you still ship webpack bundles, run multilingual UIs, or care about subtle typography controls like tabular numerals and stylistic alternates.

Tailwind CSS v4.2.0 adds a new webpack plugin, four new default color palettes, a full set of logical property utilities for block-direction spacing and borders, and new inline/block size utilities.

Where v4.2 sits in the v4 timeline

v4.0 in January 2025 shipped the new engine; v4.1 followed with text shadows, masks, and pointer variants; v4.2 is the release that fills two practical gaps the team had been signalling: non-Vite bundlers and writing-mode-aware utilities. Nothing here is breaking — v4.2 is additive on top of v4.x — but several deprecations land that you should adopt before they harden into removals.

`@tailwindcss/webpack`

Vite users have had a tight first-party plugin since the v4.0 announcement. v4.2 finally extends the same story to webpack:

const tailwind = require("@tailwindcss/webpack");

module.exports = {
  // …
  plugins: [tailwind()],
};

That replaces the old PostCSS-and-loader stack you assembled by hand. Practical effects:

• HMR behaves like the Vite path: editing a class triggers a near-instant refresh.
• Source detection runs the same Lightning-CSS-backed walker, so @source rules and .gitignore exclusions match across bundlers.
• Build output is identical to PostCSS-driven setups; you can switch later without diff churn.

If your repo is on Next.js, Nuxt, Angular, or a hand-rolled webpack config, v4.2 finally gives parity with the Vite experience.

Four new palettes

mauve, olive, mist, and taupe join the default theme — three muted neutrals plus a warm-leaning gray. Each ships the full -50 through -950 scale in OKLCH so they sit cleanly next to the existing colors. Why they matter: gray and zinc were defaults that ended up in too many designs at once, and overriding the namespace meant either redefining the whole scale or living with mismatched hues. Picking olive for editorial UI or mist for documentation gives you a distinct neutral without writing custom OKLCH values.

Logical properties, end-to-end

This is the section i18n-heavy teams have been waiting for. Until v4.2, "make this margin understand RTL" meant either CSS variables, custom utilities, or the older ms-* / me-* shortcuts (which were inline-axis only). v4.2 fills the block axis and adds size shortcuts:

• Block-axis spacing: pbs-*, pbe-*, mbs-*, mbe-* (block-start / block-end padding & margin) — useful when content rotates between horizontal and vertical writing modes.
• Block-axis borders: border-bs, border-be (and the -x / -y aware shorthand variants).
• Logical sizes: inline-* and block-* for width/height, plus min/max variants (min-inline-*, max-block-*).

Concretely, a card that wants padding above headings in horizontal flow but to the left in a vertical Japanese layout becomes pbs-4 instead of two writing-mode-specific overrides.

Typography: `font-features-*`

OpenType has had useful flags for years — tabular numerals, stylistic alternates, contextual ligatures — but Tailwind made you wire them via arbitrary CSS. v4.2 exposes font-feature-settings directly:

• font-features-tnum — tabular figures, perfect for tables and dashboards where the digits should align.
• font-features-zero — the slashed-zero alternate.
• font-features-liga / font-features-no-liga — toggle ligatures.
• Custom values via the arbitrary syntax, e.g. font-features-[ss01].

If your design system already calls out tabular numerals for metrics widgets, this is one config block you can delete.

Deprecation: `start-*` / `end-*` → `inline-s-*` / `inline-e-*`

The team is consolidating naming. The old ms-* / me-* and start-* / end-* aliases still work in v4.2, but the canonical form going forward is `inline-s-*` and `inline-e-*` to match the new block-axis utilities. Two practical actions:

• Run the upgrade tool (npx @tailwindcss/upgrade) — it rewrites the deprecated forms.
• Update your component library's documented surface so consumers adopt the canonical names.

Migration notes

v4.2 is drop-in: bumping the package and running your build is enough for most repos. Two things to watch:

• Scoped resets in dynamic imports may need a quick @source audit if your bundler split has changed.
• CI cache keys — clear once after the upgrade so the new engine version triggers a clean compile.

Worked example: a multi-language layout

Consider an article layout that needs to work in English (left-to-right, horizontal writing) and Japanese vertical mode (top-to-bottom). Pre-v4.2, a designer would maintain two parallel stylesheets or pile up writing-mode-specific overrides. With v4.2:

<article class="
  pbs-12 pbe-8
  border-bs border-bs-border
  inline-w-prose max-inline-w-screen-sm
  font-features-tnum
">
  <h1 class="pbe-2 text-2xl font-display">記事タイトル</h1>
  <time class="font-features-tnum text-fg-3">2026-04-25</time>
  <p>本文…</p>
</article>

Switch writing-mode: vertical-rl on the parent and the same classes flip orientation. The padding above the title becomes padding to the right; the bottom border becomes a left border; the inline width becomes a vertical height. No second set of class names, no JS-driven mode toggle.

This is the pattern Tailwind users with i18n needs have been hand-rolling for years; v4.2 finally makes it one of the supported defaults.

Why now (and why it took until v4.2)

The team has been clear that they didn't want to ship logical utilities until the engine could handle them ergonomically. v3 had partial support (me-* / ms-* for inline axis), but the block axis required either custom plugins or arbitrary CSS. Two reasons for the wait:

• Naming consistency. The spec uses block-start / block-end / inline-start / inline-end, but Tailwind needed shorthands that read well in JSX. pbs-* and mbe-* are the team's bet on a notation that's both legible and future-proof.
• Variant interaction. Logical utilities should compose cleanly with hover:, md:, group-*, etc. The v4 engine made that easy; v3 would have required engineering elsewhere.

If you've been waiting for first-class logical properties as your reason to migrate to v4, this is the release that closes the gap.

Official references

• GitHub release v4.2.0
• Laravel News write-up
• Logical properties — MDN reference

Source / further reading: Laravel News