Sasso Ffi Laravel Package

Product Decisions This Supports

• In-process SCSS compilation vs. external build step. shyim/php-sasso-ffi binds PHP directly to libsass via FFI, so SCSS can be compiled at runtime or in a queue worker without a Node/npm toolchain in the deploy image. This is a real decision point for teams running Laravel on shared hosting, Laravel Cloud/Fly/Forge-style single-runtime containers, or environments where adding Node to the pipeline is disproportionate.
• Replacing legacy PHP compilers. It is a candidate alternative to leafo/scssphp (slow, stale, partial Sass feature support) and to scssphp forks. If design-system SCSS uses modern Sass constructs, this is the "build vs. buy vs. keep the old library" call.
• Removing Node from the build/deploy pipeline. Useful where SCSS is compiled on-demand (theme builders, multi-tenant white-labelling, user-editable stylesheets) rather than at build time — the case where a compile-on-request PHP path beats a precompiled CSS artifact.
• Roadmap: dynamic theming. Multi-tenant or customer-supplied SCSS with per-request variable injection becomes feasible if compile latency is acceptable; this is a product capability, not just an infra swap.
• Build vs. buy for binary delivery. Release 0.1.1 adopting shyim/composer-binary-downloader shifts the native-library problem from "document how to compile libsass" to "fetch a prebuilt binary during Composer install." That is a packaging/ops stance: you are buying downstream binary-distribution maintenance rather than owning it, which lowers integration cost but introduces a Composer-install-time network and supply-chain dependency.

When to Consider This Package

Consider it when:

• You need Sass/SCSS compilation inside PHP without a Node runtime, and you accept a native dependency.
• Your PHP build has FFI enabled (ffi.enable=On or preload), which is not the default in many hardened production configurations — this alone can be the deciding gate.
• Your deployment target is one of the platforms for which the downloader can resolve a prebuilt libsass binary; verify against your actual CI and production image (musl vs. glibc, ARM64, Windows).
• You can tolerate a 0.1.x pre-1.0 API: expect breaking changes, thin documentation, and a small maintainer surface.
• You want a single-maintainer, narrow-scope dependency rather than a broader extension (e.g. ext-scss) or a managed SaaS compiler.

Look elsewhere when:

• You can precompile CSS at build time — a Node/Sass step in CI is cheaper in risk than a runtime native dependency, and most Laravel apps should default to this.
• FFI is disabled by policy, or you cannot guarantee the extension in every environment (shared hosts, some PaaS runtimes).
• You need guaranteed long-term support, a security-response process, or an SLA — neither exists at 0.1.x.
• Your Composer installs run in air-gapped or heavily restricted networks; a downloader that fetches at install time is an obstacle. Confirm whether it supports vendored/offline binaries before committing.
• Sass feature parity matters (e.g. newer @use/module-system semantics) — libsass trails Dart Sass, which is the reference implementation.

Release-specific note (0.1.1): This is an infrastructure change, not a feature change — the binary acquisition path is now delegated to shyim/composer-binary-downloader. Functionally nothing was added; operationally, installs now depend on that downloader resolving a suitable artifact. Pin the version, verify a clean composer install in a network-restricted CI job, and confirm the binary is cached/committed if your pipeline requires reproducibility.

How to Pitch It (Stakeholders)

For executives: This is a small, pre-1.0 open-source library that lets our Laravel application compile Sass stylesheets natively in PHP instead of maintaining a Node.js build step. The 0.1.1 release doesn't add capability — it changes how the underlying compiler binary is obtained, moving from a manual setup burden to an automated download during dependency install. Net effect: cheaper to adopt, same immaturity risk. It is a single-maintainer dependency with no support contract; treat it as a tactical convenience, not a platform commitment.

For engineering: FFI-bound libsass. Requires ffi.enable and a compatible native binary; 0.1.1 delegates binary fetching to shyim/composer-binary-downloader, which removes the compile-from-source toil but adds an install-time network fetch and a supply-chain surface we should review (source of binaries, checksum verification, offline fallback). API is 0.1.x and unstable, so isolate it behind our own ScssCompiler interface so we can swap to Dart Sass, scssphp, or a build-time step without touching call sites. Recommended adoption pattern: use it for dynamic/runtime theming where a build step genuinely cannot reach, precompile everything else in CI, and add a smoke test that compiles a representative stylesheet on each supported platform image. Re-evaluate on 1.0 or if the maintainer stops publishing.