Jaxon Utils Laravel Package

Getting Started

• Install with composer require <vendor>/<package>. Laravel auto-discovery registers the service provider and the Minify facade, so no manual config/app.php edits are needed on modern Laravel.
• Publish the config (php artisan vendor:publish --tag=minify-config) and read config/minify.php first — it is where encoding, asset-path, and driver options live.
• First use case: minify small runtime-generated CSS/JS strings (theme overrides stored in the DB, per-tenant snippets) before injecting them into a Blade view. As of v2.1.0 there are four entry points — JS code, CSS code, JS file, CSS file. Start in tinker with the code variants (Minify::css('body { color: red; }')) to confirm the output and method names, then graduate to the file variants for build/deploy work.
• If you are upgrading from 2.0.x, diff the old combined minify call against the new split methods before changing application code; the "separate functions" change is the first thing to verify.

Implementation Patterns

• Runtime string minification. Use the JS/CSS code functions for dynamic assets, and always cache the result (Cache::remember keyed on a hash of the source) — minification is CPU-bound and should never run raw on every request.
• Build/deploy time file minification. The file functions are the right tool for an artisan command or deploy script: walk public/css and public/js, write .min. output, then run your cache-busting/versioning step. This is the pattern that scales; runtime minification of static files rarely is.
• Blade integration. Wrap the code functions in a Blade directive or a small helper so views can emit minified inline blocks without leaking service classes into templates.
• Coexist with Vite/Mix. Do not re-minify bundler output. Use this package for legacy assets that bypass the bundler, or for files generated outside the JS toolchain.
• Environment gating. Minify only in production, or gate on a config flag, so local debugging keeps readable source. Pair with a local/testing bypass in the config.
• Pipeline order. Minify → hash/version → cache-bust. Doing it out of order produces stale URLs, especially if the file functions write to a different directory than the source.

Gotchas and Tips

• Split API is the migration risk. v2.1.0 separates JS vs. CSS and code vs. file minification. Semver says minor, so the old combined method is probably deprecated rather than removed — but grep the codebase for old calls and confirm the old signature still behaves. Test before shipping.
• JS minifier upgrade is a regression surface. A new underlying minifier version can change how modern syntax is handled (optional chaining, class fields, ES2020+). Run your JS smoke tests or at least a representative bundle through it. Check whether the new library bumped the minimum PHP version.
• CSS minifier edge cases. Watch calc() whitespace, CSS custom properties, and url() references. File minification resolves url() relative to the source file; if output lands in a different directory, relative paths break — keep output alongside the source or pass an explicit base path.
• Don't double-minify. Running the minifier over already-minified vendor bundles can break source maps and occasionally produce invalid output. Keep a skip list in config.
• Know whether file functions return or write. Depending on version, file minifiers either return the minified string or write to disk. Handle unreadable files and false/exception returns explicitly.
• Encoding. Ensure inputs are UTF-8 without BOM; a stray BOM survives minification and breaks the first CSS rule or JS statement.
• Debugging. Keep a bypass flag and diff raw vs. minified output when something renders wrong. Disable minification in local and testing so stack traces and line numbers stay usable.
• Extension point. The config's driver option is the clean seam for swapping the underlying minifier — useful for pinning behavior in tests or isolating a regression after the library upgrade.