Tailwind 3.x config: should the legacy purge key be kept or fully replaced by content
0 reputation · 02 Jan 2022, 17:31 UTC
0 reputation · 02 Jan 2022, 17:31 UTC
In a Tailwind CSS 3.x project, the content array in tailwind.config.js controls which files are scanned so unused utilities are removed from the production build. Older guides and some starter templates still use the legacy purge key for the same purpose, and it is unclear whether both keys are honored, whether one silently overrides the other, or whether purge is simply aliased for backward compatibility.
The goal is to settle on one canonical configuration for a new project that must also stay understandable to teammates migrating from Tailwind 2.x setups. The concern is that a duplicated or deprecated key could mask misconfigured file paths, causing classes to be dropped from the production CSS without an obvious warning.
Assume Tailwind CSS 3.x with the default JIT compiler and a build run via the Tailwind CLI.
Does Tailwind 3.x treat purge as a deprecated alias of content, and what happens if both keys are present with different globs? Is there any documented scenario where keeping purge changes scanning behavior? Should new projects standardize on content only?
35775 reputation · 03 Jan 2022, 00:02 UTC
In Tailwind CSS 3.x, you should fully replace the purge key with the content key. The purge key is a legacy artifact from version 2.x and is deprecated in version 3.x. New projects should standardize on content only to ensure configuration clarity and avoid potential debugging hurdles during production builds.
The shift from purge to content represents a fundamental change in how Tailwind handles CSS generation. In version 2.x, Tailwind generated a massive set of all possible utilities and then used PurgeCSS (via the purge key) to remove unused ones. In version 3.x, the Just-in-Time (JIT) engine is the default; it scans your files and generates only the CSS you actually use.
While Tailwind 3.x may maintain some backward compatibility to prevent immediate build failures during migrations, the JIT engine prioritizes the content array for generating the CSS bundle. If both keys are present with different globs, you risk creating a "split source of truth." This can lead to scenarios where a developer updates the purge array but notices no change in the production build because the engine is ignoring it in favor of the content array.
purge array against your content array. Ensure all paths to templates, components, and JavaScript files are captured in content.purge key entirely from tailwind.config.js.// tailwind.config.js
module.exports = {
// ✅ Use this
content: [
'./src/**/*.{html,js,jsx,ts,tsx}',
],
// ❌ Remove this
// purge: ['./src/**/*.html'],
theme: {
extend: {},
},
plugins: [],
}
To verify that your content configuration is working as expected, run a production build and check the output file size:
npx tailwindcss -i ./src/input.css -o ./dist/output.css --minify
Diagnostic Detail Needed: Are you using any custom PurgeCSS plugins or a highly non-standard build pipeline (e.g., a legacy Webpack wrapper) that specifically expects the purge key for external post-processing?
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.