- How do I install shyim/sasso-ffi in a Laravel application?
- Run composer require shyim/php-sasso-ffi. You need PHP 8.1 or newer with ext-ffi available, and the libsass shared library must be present on the host. Since 0.1.1 the package can fetch a prebuilt libsass binary through a Composer plugin, so you must add an explicit allow-plugins entry in composer.json and allow network egress during composer install. There is no Laravel package discovery step, so nothing is auto-registered.
- Does shyim/sasso-ffi require a PHP extension or Node.js to compile Sass?
- It requires no native PHP extension of its own, no C++ build step on your part, and no Node or Dart Sass toolchain or subprocess. Compilation happens in-process through PHP FFI calling into the libsass shared library. That said, ext-ffi must be enabled, and the libsass .so/.dll/.dylib has to be resolvable at runtime, either downloaded as a prebuilt artifact or built from source.
- Which Laravel and PHP versions does shyim/sasso-ffi support?
- It works with Laravel 10, 11 and 12 applications running PHP 8.1 or newer, provided ext-ffi is enabled. Because the package ships no framework integration, Laravel version compatibility mainly depends on your PHP version and FFI availability rather than on Laravel internals. Check the composer.json constraints of the specific 0.1.x release you adopt, since the API is not frozen.
- Does shyim/sasso-ffi support the modern Sass module system with @use and @forward?
- No. It binds to libsass, which is end-of-life upstream and frozen at the pre-@use language level. Stylesheets relying on @use, @forward, modern color functions, or newer CSS syntax will not compile. Treat the package as a bridge for legacy @import-style SCSS corpora rather than a long-term foundation.
- Is there a Laravel service provider, facade, or Blade directive for shyim/sasso-ffi?
- No. The package is a plain library with no service provider, facade, config file, or Blade directive. Your first integration means writing your own singleton binding in a service provider, a caching layer, and error mapping yourself. That is straightforward but is work you own and must maintain.
- Is shyim/sasso-ffi safe to use with Laravel Octane and queue workers?
- FFI requires ext-ffi to be enabled, and the hardened ffi.enable=preload mode conflicts with loading libsass lazily at runtime, so you must choose between loosening FFI hardening and preloading at opcache boot. Load the library once as a singleton rather than per request. Whether the bound libsass context is thread-safe under Octane's worker model and queue workers should be verified with a load test before production use.
- How does shyim/sasso-ffi compare to scssphp for Laravel projects?
- Both are pure-PHP-friendly options that avoid a Node toolchain, but scssphp is implemented in PHP while this package calls the native libsass compiler via FFI. You gain speed and more correct handling of Sass edge cases, and you take on an FFI dependency plus a binary-download surface. Migrating from scssphp is lower risk on output parity and higher risk on installation.
- How do I handle SCSS compile errors and warnings in Laravel?
- Compile failures surface from the underlying libsass call, so wrap compilation in a try/catch inside your own service class and map the results into Laravel exceptions or a validation-style error bag. Check the release you use to confirm whether errors and warnings arrive as structured PHP exceptions, because mapping depends on that. Reporting warnings, such as deprecation notices, into your logs during a migration is worth doing so output drift is visible early.
- Does shyim/sasso-ffi work on Alpine, arm64, and Windows, and what happens without a prebuilt binary?
- Prebuilt artifact availability per OS, architecture, and libc determines where the package works, so glibc versus musl on Alpine, arm64, and Windows each need checking against the published matrix. Before 0.1.1 you could always fall back to compiling libsass from source; with the binary downloader, confirm the documented fallback and whether checksums are verified. For air-gapped or mirrored CI, verify whether the downloader can consume a pinned or vendored artifact.
- Should I compile SCSS at build time or at runtime with shyim/sasso-ffi?
- Compile at build or deploy time where possible and cache the resulting CSS, because that is where this package fits best and where output is easiest to diff and invalidate. Runtime compilation works for dynamic theming but puts FFI and libsass availability on your request path. If you do compile at runtime, cache aggressively and compile both old and new pipelines behind a config flag to compare CSS output before cutting over.