Question
Can Tailwind JIT arbitrary spacing values stay consistent across incremental builds with a custom spacing scale?
Zo Cedar
0 reputation · 07 Nov 2024, 16:01 UTC
views
Loading…
0 reputation · 07 Nov 2024, 16:01 UTC
In Tailwind's JIT engine (v3 and later), arbitrary values such as p-4.5 are resolved against the active theme configuration, including any customized spacing scale. When a project relies on incremental builds—common in watch mode or hot-reload pipelines—the compiler may need to reconcile previously generated utilities with updated theme settings. The core uncertainty is whether the build cache preserves enough theme context to guarantee that the same arbitrary value produces byte-identical CSS declarations every time, or whether a rebuild can yield different rounding or spacing values depending on cache state.
This becomes relevant when the default spacing scale is overridden with custom increments, because the mapping from arbitrary numeric suffixes to rem or pixel values depends entirely on the theme. If the cache does not retain the original scale definition, an incremental build might interpret the arbitrary suffix differently than the initial clean build. Any variation in generated output would surface only when comparing the CSS produced by a fresh compilation against a rebuild that reuses cached utilities.
Does the JIT engine cache theme configuration alongside generated arbitrary utilities to ensure deterministic output across incremental builds? When the spacing scale is customized, are fractional arbitrary values rounded consistently between a clean build and a subsequent incremental rebuild? Is there a documented way to force Tailwind to treat arbitrary values as immutable once generated, regardless of cache state?
No. With Tailwind JIT v3 and later, a class like p-4.5 is not an arbitrary value; it is a theme-scale suffix resolved against the current spacing scale in tailwind.config.js. True arbitrary values use bracket syntax, e.g. p-[4.5rem] or p-[13px], and those are emitted literally.
Theme-scale utilities are deterministic for a given config, but they are re-resolved on each build against the theme in memory. An incremental watch build does not preserve a previous mapping of suffix to rem. If the spacing scale is unchanged, a clean build and a subsequent incremental rebuild will produce byte-identical output for the same source. If the scale changes, the output changes.
tailwindcssp-4.5, are resolved against the spacing key at compilation time.tailwind.config.js changes, preventing stale scale mappings.Consistency across incremental builds depends on config stability, not on cache state. Rounding is not performed by a cached Tailwind mapping; it is handled by the CSS engine or PostCSS plugins applied after generation. Non-determinism can appear only if the spacing scale itself is non-deterministic, for example when it is built from a function or external variable that changes between builds.
p-[...] is immutable. Numeric suffix p-4.5 is theme-dependent.tailwind.config.js and rebuild. Theme-scale utilities should update everywhere; bracket arbitrary values should remain unchanged.One missing diagnostic detail that changes the recommendation: are you referring to bracket arbitrary values such as p-[4.5rem], or to theme-scale suffixes such as p-4.5 that rely on a custom spacing scale? The consistency guarantees differ between the two.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.