Sasso Ffi Laravel Package

Technical Evaluation

Architecture fit — shyim/php-sasso-ffi is a thin PHP FFI binding over libsass, giving PHP an in-process SCSS → CSS compiler with no ext-*, no Node/Dart toolchain, and no subprocess. For a Laravel app already running PHP-only containers, it removes an entire runtime dependency from the asset pipeline. Fit is strongest where SCSS is compiled at build/deploy time and the output is cacheable; it is a poor fit where the codebase depends on the modern Sass module system, since libsass is end-of-life upstream and frozen at the pre-@use language level.

Integration feasibility — Simple as a library: composer require shyim/php-sasso-ffi. It ships no Laravel service provider, facade, config file, or Blade directive, so first integration means writing our own singleton binding, cache layer, and error mapping. The 0.1.1 change lowers the floor meaningfully: adopting shyim/composer-binary-downloader fetches a prebuilt libsass shared object instead of requiring headers and a C++ toolchain on every host. That converts a "compile it yourself" onboarding problem into a "trust a Composer plugin" problem — a trade worth making, but a different review, not a smaller one.

Technical risk

• Lifecycle (high, unchanged by 0.1.1): libsass is deprecated upstream and gets no feature work. Anything using @use/@forward, modern color functions, or newer CSS syntax will not compile. This is the dominant long-term risk and the reason to treat the package as a bridge, not a foundation.
• FFI posture (medium): requires ext-ffi; the hardened ffi.enable=preload mode conflicts with lazily loading the library at runtime, so we choose between loosening FFI hardening and preloading at opcache boot. That's a security review item.
• Install-time code execution (new in 0.1.1, medium): a Composer plugin downloads platform-specific binaries during composer install. This needs an explicit allow-plugins entry, network egress in CI/build, and a documented answer on checksum verification and mirroring before it clears a supply-chain gate.
• Maturity (medium): 0.1.x, single primary maintainer, no 1.0 API freeze. Semver does not protect us here.
• Platform coverage (medium, changed by 0.1.1): prebuilt artifact availability per OS/arch/libc now determines where the package works — glibc vs musl (Alpine), arm64, Windows. Previously we could always fall back to building from source.

Key questions

1. Does the binary downloader verify checksums, and can it consume a pinned/vendored artifact or internal mirror for air-gapped CI?
2. Which (OS, arch, libc) triples have prebuilt artifacts, and what is the documented fallback when none match — source build, or hard failure?
3. Is libsass loaded once as a singleton, and is the compiler object safe to reuse across requests under Octane?
4. What is the maintainer's stated position on libsass EOL — is a dart-sass / sass-embedded path in scope?
5. Are compile errors and warnings surfaced as structured PHP exceptions we can map into Laravel's error handling?
6. Is the bound libsass context thread-safe, and how does that interact with queue workers and Octane's worker model?

Integration Approach

Stack fit — Works for any Laravel 10/11/12 app on PHP 8.1+ with ext-ffi available. First-class fit for teams that want zero non-PHP build tooling and are compiling a legacy SCSS corpus (Bootstrap-era, @import-style partials). Poor fit for design systems already on the Sass module system, or for projects needing PostCSS/Tailwind-style plugin chains — this package compiles Sass and nothing else.

Migration path

• From node-sass / dart-sass in an asset pipeline: run both paths behind a config flag against the real stylesheet corpus and diff the CSS before cutting over. Output drift (rounding, source maps, deprecation handling) is the realistic failure mode, not crashes.
• From scssphp (pure PHP): lower risk on output parity, higher risk on install. Gain is speed and correct edge-case handling; cost is the FFI + binary-download surface. Put the swap behind the same compile interface so it stays reversible.
• From the 0.1.0 source-build install: 0.1.1 is strictly easier, but treat it as a CI/Docker change rather than a code change — drop libsass build steps from images, add the allow-plugins entry, and cache the Composer layer so builds don't re-download each run.

Compatibility — Pin exactly (0.1.1, not ^0.1) until 1.0. Confirm PHP and Laravel version bounds, ext-ffi presence in every image (queue worker and scheduler too, not just web), and glibc/musl parity between laptops and production base images. Lock the Composer plugin version as well — it is now part of the build graph.

Sequencing

1. Spike: install on a scratch branch, compile the full stylesheet corpus, diff against current output. Gate on byte-parity or documented, accepted deltas.
2. Harden the supply chain: confirm checksum verification and mirror story; get security sign-off on the Composer plugin and the FFI enablement mode.
3. Wrap it: a small internal SassCompiler contract with a cache keyed on source hash plus import graph, bound as a singleton; expose via a Blade helper only after the wrapper is stable.
4. Roll out to one non-critical surface, then the full build, keeping the old pipeline behind a flag for one release cycle.
5. Only then remove node/dart-sass from images.

Operational Impact

Maintenance — Small code surface (a wrapper plus a cache) but a non-trivial dependency tail: PHP minor upgrades can break FFI struct bindings, libsass is frozen upstream, and the package is pre-1.0 with one maintainer. Budget a standing "re-verify on PHP upgrade" line item rather than assuming it is inert. Realistically this is a two-to-three-year bridge with a known exit.

Support — No vendor. Support is GitHub issues plus reading libsass C API docs when something breaks. Internal runbooks must own: how to pin and upgrade, how to mirror binaries, how to diagnose FFI load failures, and how to fall back to the previous pipeline. Name a single owner; this should not orphan in a platform team's backlog.

Scaling — Compilation is CPU-bound inside the PHP process. For build-time compilation this is irrelevant. For runtime compilation it competes with request workers: cap it, cache aggressively (source hash + all partials), and never compile in a hot request path — compile on deploy or in a queue. Under Octane, verify the libsass handle's lifecycle across worker restarts; a leaked FFI handle per worker is a slow memory climb that is very hard to attribute later. Preloading the library can cut per-process init cost if we accept ffi.enable=preload.

Failure modes to plan for

• Binary download fails (no egress, proxy, unsupported platform) → composer install fails outright. Mitigation: mirrored artifact, cached layer, documented source-build fallback.
• FFI disabled in a drifted image (staging green, prod red) → runtime fatal on first compile. Mitigation: boot-time health check that fails fast and loudly.
• Unsupported SCSS syntax (@use) → compile exception at build. Mitigation: lint the stylesheet corpus against libsass in CI.
• Output drift vs. the previous compiler → silent visual regressions. Mitigation: keep the CSS diff gate in CI permanently.
• Native crash inside libsass (segfault through FFI) kills the PHP worker with no catchable exception. Mitigation: keep runtime compilation out of the request path or isolate it in a dedicated queue.
• Pre-1.0 breaking change on a routine composer update → Mitigation: exact pins plus mandatory lockfile review.

Ramp-up — A Laravel developer can integrate this in under a day; it is a library call behind a wrapper. The real learning cost sits elsewhere: FFI enablement and its security trade-offs, the new Composer plugin/binary-download build step, and libsass's language limitations versus modern Sass. Estimate ~1 day engineering and ~2–3 days for output-parity validation plus security/CI review — that review, not the code, is the critical path. Front-load it before committing the team to removing the existing asset pipeline.