Weave Code
Assetic Filters Laravel Package
cartalyst/assetic-filters
Cartalyst Assetic Filters extends Assetic with additional asset filters for Laravel projects, making it easier to preprocess and compile CSS, JavaScript, and related front-end assets in Cartalyst-based applications.
Additional assetic filters (such as a PHP SASS compiler) to enhance Assetic.
Frequently asked questions about Assetic Filters
- Does cartalyst/assetic-filters support Laravel 8 and newer?
- The latest release, v5.0.0, was updated for Laravel 8, and that release note reflects Cartalyst ecosystem alignment rather than a hard framework requirement. Because the package is a build-time Assetic filter library rather than a runtime package, Laravel version coupling is loose; the real constraint is whether Assetic is in your asset pipeline at all. Nothing in the repository indicates it has been tested against Laravel 9, 10, or 11, so treat anything newer than Laravel 8 as unverified.
- How do I install cartalyst/assetic-filters in a Laravel project?
- Install it with composer require cartalyst/assetic-filters, then register the filters you need in whatever Assetic configuration your build already uses. There is no service provider to register, no config file to publish, and no migrations to run. The package only becomes useful once an Assetic compilation step exists in a Composer script, a CI job, or a dev watcher.
- Do I need Assetic installed to use this package?
- Yes. Cartalyst Assetic Filters supplies additional filters that plug into Assetic's filter collection, so without an Assetic pipeline there is nothing for it to extend. If your project uses Vite, Laravel Mix, or Webpack Encore, you already have a different pipeline and this package adds nothing to it. If Assetic is not in your stack today, the practical answer is not to adopt it.
- Does the Sass filter require Node, Ruby, or a native libsass binary?
- The headline filter is a PHP-based SASS compiler, but a compiler filter can either wrap a native binary or a PHP port of a compiler, so confirm which before sizing any integration. Both approaches introduce reproducibility risk through version drift and platform-specific binaries in the build image. Check whether Node, Ruby, or libsass must be present in CI, note the exact compiler version, and pin all of it explicitly.
- Does cartalyst/assetic-filters run on PHP 8.1, 8.2, and 8.3?
- The last release was December 2020, so there is no evidence it has been exercised against PHP 8.1, 8.2, or 8.3. With roughly six stars and zero dependents, your team would likely be the first to hit any incompatibility. Run a spike on your target PHP version before committing, and record the result in a documented compatibility matrix.
- What filters does cartalyst/assetic-filters actually provide?
- It adds Assetic filters for precompiling LESS, Sass/SCSS, and CoffeeScript into standard CSS and JavaScript, plus minification of CSS and JS output for production. Filters can be chained in a single pass, so preprocessing and minification run together. The package wires Assetic's filter collection into Laravel's container and configuration conventions rather than shipping its own asset pipeline.
- Is this a runtime Laravel package with a service provider and config file?
- No. It is a build-time filter library that runs during asset compilation, not in the request lifecycle, so expect no service provider, no publishable config, no facades, no migrations, and no queue integration. That keeps the blast radius confined to the build pipeline rather than production traffic. Any estimate built on the standard Laravel package checklist is sized against the wrong integration shape.
- Is cartalyst/assetic-filters maintained, and should I use it on a new project?
- Adoption is minimal, with roughly six stars, zero dependents, and a last release in December 2020, while Assetic itself is effectively dormant in the PHP ecosystem. A filter library is only as viable as the pipeline it extends, so the parent project's health matters more than this repo's. Use it only as a short-term bridge on applications already running Assetic; for new work, Vite is the strategic direction for PHP asset compilation. The BSD-3-Clause license is permissive and keeps the fork option open if the project is abandoned.
- What are the production risks of compiling assets with this package?
- Risk is medium-to-high and concentrated in upstream decay, toolchain dependency, and currency rather than spread evenly across the codebase. For production, pin an explicit matrix of PHP version, Assetic version, package version, compiler binary version, and CI image so builds stay reproducible. Confirm compiled CSS output is byte-comparable with your current pipeline before switching a release over to it.
- How do I migrate off Assetic and cartalyst/assetic-filters later?
- Sequence it as inventory, bridge, then exit. First list every asset entry point and the specific filter each one uses, then adopt v5.0.0 only as a short-term bridge if asset compilation is blocking a framework upgrade. Schedule the Assetic retirement as a separate, visible workstream with a named owner so the bridge does not quietly become permanent, which is the default failure mode for build tooling.
Weaver
How can I help you explore Laravel packages today?