Asset Minifier Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy on the asset pipeline. The package now minifies both JS and CSS out of the box, which removes one of the last reasons a small-to-mid PHP app needs a bespoke frontend build step just to ship compressed assets. This is a "buy" (adopt) decision, not a "build" one.
• Roadmap sequencing for frontend modernization. Teams can defer investment in a full Vite/webpack migration and still ship production-grade minified output. That frees the next one or two sprints for product work instead of tooling.
• Feature scope for server-rendered apps. Admin panels, internal tools, marketing sites, and Blade/Twig-heavy apps where the JS surface is small and mostly vendor libraries are the sweet spot. The release makes CSS-heavy pages (the common case) benefit too, not just script bundles.
• Operational cost reduction. Fewer moving parts in CI/CD and deploy: no Node runtime required on build agents or servers, no separate minification step to maintain or debug.
• Tailwind adoption decision. Explicit compatibility with symfonycasts/tailwind-bundle — Tailwind compiles, esbuild minifies the output — means a Tailwind migration is no longer blocked on "how do we compress the generated CSS." That unblocks a design-system or UI refresh conversation.
• Legacy/consumer-browser compatibility trade-off. Deliberate preservation of rgba()/hsl() formats and skipping vendor CSS is a signal the maintainers optimize for correctness over maximum compression. Supports decisions to keep supporting older browser matrices rather than forcing a design-token rewrite.

When to Consider This Package

Consider it when:

• The app is PHP-centric (Symfony AssetMapper-style config, asset_minifier YAML keys) and the team does not want Node in the production or CI path.
• You already have, or are about to add, symfonycasts/tailwind-bundle — the compile-then-minify ordering is handled.
• Your asset graph is simple: a handful of app-owned JS/CSS files plus vendor libraries you are content to ship unminified (or already ship minified).
• You want a low-ceremony default: both minify_js and minify_css default to true, and existing behaviour is unchanged, so adoption is a non-event for current users.
• You need a reversible toggle — the two config flags let you disable either pipeline independently if a minification bug surfaces.

Look elsewhere when:

• You need bundling, tree-shaking, code splitting, ES module transpilation, or TypeScript. This is a minifier, not a bundler; it compresses what you give it.
• You are on a Vite/Laravel Mix/webpack pipeline that already minifies in production. Adding this duplicates work and creates two sources of truth.
• Your CSS correctness depends on aggressive optimizations this package deliberately avoids (color rewriting, vendor CSS processing) — you would be paying for behaviour it intentionally does not provide.
• You are a Laravel shop expecting first-class Laravel integration; the configuration shown (asset_minifier YAML, Tailwind bundle coupling) reads as Symfony-ecosystem. Verify framework fit before committing — a mismatched integration is the main adoption risk here.
• Frontend performance budgets require sub-resource integrity, critical-CSS extraction, or per-route asset graphs. Out of scope.

Adoption criteria to check before committing: framework/ecosystem alignment, whether vendor CSS minification gaps matter for your page-weight targets, and whether an existing build step already covers JS.

How to Pitch It (Stakeholders)

For executives (one paragraph): This release adds CSS minification to a package we already use for JavaScript, so every stylesheet we ship is now smaller with no new tooling, no new vendor contract, and no code changes — both settings default to on and existing behaviour is unchanged. The practical effect is faster page loads for our CSS-heavy screens and one less reason to stand up a separate frontend build pipeline. Risk is low: it is a configuration toggle, individually switchable per asset type, and it preserves colour formats specifically to avoid breaking older browsers. Recommendation: adopt on the current release, monitor page-weight and any styling regressions for one cycle, and treat the removal of a Node-based build step as a candidate roadmap saving.

For engineering (talking points):

• CSS is minified via --minify --supported:hex-rgba=false; shorthand merging is applied (e.g. four margin-* declarations collapse to one).
• Colour values are intentionally left in source format (rgba() stays rgba(), hsl() stays hsl()) — a deliberate compatibility choice, not an oversight. Do not "fix" it.
• Vendor CSS is skipped by design; size gains are on app-owned CSS only. Set expectations accordingly.
• Ordering with Tailwind is correct: Tailwind compiles first, esbuild minifies the output. No manual wiring needed.
• New knobs: asset_minifier.minify_js and asset_minifier.minify_css, both defaulting to true. Use them as kill switches if a specific asset misbehaves.
• No breaking changes, no deprecations. Upgrade is a version bump; the only validation worth doing is a visual diff on the most style-dense pages and a check that no build step is now minifying the same files twice.