Phpsass Laravel Package

Product Decisions This Supports

• Pipeline architecture: build vs. buy vs. compile-in-PHP. The real product question is not "which Sass compiler do we pick" but "does stylesheet compilation live inside our PHP application, or in a Node/Dart Sass asset pipeline (Vite, Laravel Mix)?" cartalyst/phpsass answers only the narrow "no Node in the deploy path" version of that question — and it is the weaker form of that answer, because a maintained pure-PHP alternative (scssphp/scssphp) exists with a similar shape. Frame the decision as pipeline architecture, not package selection.
• Maintenance track vs. new investment. This is a keep-the-lights-on input, not a greenfield architecture input. It becomes relevant when an existing product already runs on the Cartalyst stack (Theme / Platform / Sentinel) and the theme layer assumes an in-PHP compiler. It should never appear in a roadmap or an RFP for new work.
• Runtime/dynamic theming feature bets. White-label branding, per-tenant stylesheets, and admin-editable storefront themes often get specced as "compile stored SCSS at request time" — and that framing creates this dependency. The stronger product decision is to compile design tokens to CSS custom properties at build time: same white-label capability, faster, safer, and it removes the compiler from the request cycle entirely.
• Deployment-constraint scoping. Where hosting policy, shared hosting, air-gapped environments, or team skillset block Node/Dart Sass, this package can unblock a release. That is a legitimate but tactical decision with a bounded lifespan — record the constraint, because when it disappears the dependency should too.
• Dependency portfolio / tech-debt triage. With 0 stars and 0 dependents, adopting this is self-owned code from day one. It belongs on the tech-debt register with a named owner, a pinned version, and explicit exit criteria — not on a "libraries we like" list.
• Containment scope. If adopted, the accompanying decision is that no application or Blade code calls it directly; everything goes through a single StylesheetCompiler contract. That converts an irreversible vendor choice into a one-line container binding and is the cheapest risk control available.
• Vendor-diligence precedent (and a flag on this package). The marketing copy describes the package as a "PHP wrapper for libsass," while the code lineage traces to richthegeek/phpsass, a port of early Ruby Sass — a pure-PHP parser, not a libsass binding. That contradiction matters to a PM for two reasons: it changes the performance and language-coverage profile materially, and it is a documentation-integrity signal about an unmaintained package. Verify the claim from source before it appears in any estimate or deck.

When to Consider This Package

Consider it only when all of the following hold:

• Existing legacy stack, not new work. The application is already on the Cartalyst/Laravel legacy stack and the theme layer already assumes a PHP-side compiler. This is a migration-avoidance decision, not a capability decision.
• The SCSS surface is small, static, and legacy. Variables, nesting, mixins, and imports only. No @use/@forward, no math.div, no module system, no modern functions. This dialect is early Ruby Sass, not Dart Sass — modern-built stylesheets either fail loudly (acceptable) or compile with subtly wrong semantics (not acceptable).
• Node/Dart Sass is genuinely blocked. Shared hosting, air-gapped environments, restrictive CI images, or a team with no JavaScript skillset. Document the constraint explicitly and put a review date on it — it is a tactical unblock, not a permanent architecture.
• You have run the parity spike and the diffs are cosmetic. Compile the full production stylesheet set with this package and with Dart Sass, then diff. Explainable cosmetic diffs = contained legacy dependency. Structural diffs (missing rules, wrong values, dropped media queries) = stop and go to scssphp/scssphp.
• You accept ownership. PHP 8.x compatibility, autoloading quirks, error-handler collisions, and include-path resolution are all your team's problem. There is no CVE process and no upstream to escalate to.

Look elsewhere when any of the following apply:

• The project is greenfield. Use Vite or Laravel Mix with Dart Sass. It is faster, maintained, standards-compliant, and has a healthy ecosystem. This package should not appear in a new architecture diagram.
• You need modern Sass language features. scssphp/scssphp supports a much later Sass dialect with a similar compile API and active maintenance — it is the drop-in swap target.
• You need dynamic/per-tenant theming at runtime. Compile design tokens to CSS custom properties at build time and emit per-tenant values from the database. This is faster and deletes the compiler from the request cycle.
• Performance matters. Pure-PHP parsing is CPU-bound and materially slower than libsass or Dart Sass — a 200ms build can become 10+ seconds on a large stylesheet set.
• The input is user-editable or request-time. An unmaintained parser with no security process, handling arbitrary input, is a denial-of-service and correctness risk.

How to Pitch It (Stakeholders)

For executives — the one-paragraph version:

This is a legacy maintenance input, not a strategic investment. It lets an existing Cartalyst/Laravel product compile SCSS without Node or Ruby in the deploy path, which unblocks teams on constrained hosting. It is unmaintained, has no community around it (0 stars, 0 dependents), and its own documentation misdescribes what it is — so we treat it as self-owned code from day one: pinned version, single interface, named owner, dated exit criterion. If we are starting anything new, the answer is Vite/Dart Sass, and we should not be having this conversation.

For engineering — the framing:

• The decision is pipeline architecture, not package choice. We are choosing whether stylesheet compilation lives inside the PHP app or in a Node build step. This package is only the narrowest "no Node at deploy time" answer, and it is the weaker form of that answer because scssphp/scssphp exists.
• Containment is non-negotiable. No Blade template, controller, or model touches the parser. It lives behind a StylesheetCompiler interface bound once in the container, driven by an Artisan command in the deploy path, and covered by golden-file tests. When we swap, one class changes.
• Day-one validation is a parity spike, not an integration. Diff our full production stylesheet set compiled by this package against Dart Sass. Cosmetic diffs → proceed. Structural diffs → go straight to scssphp/scssphp. This single diff is the go/no-go, and it costs an hour.
• Plan for PHP 8.x friction. The lineage is PHP 5.3–7.x era. Expect deprecations, possible fatals, and a composer.json constraint that may block installation outright. Validate against both ends of the CI matrix, and confirm composer install --no-dev -o in a clean container before relying on it.
• Ship the runbook and the exit note with the integration. One page on how to recompile and regenerate fixtures; one page naming the swap target, the interface, and the validation steps. The person who can replace this in an afternoon is the person who wrote that note — make sure it exists before they change teams.

The honest recommendation: adopt only as a documented tactical unblock inside an existing Cartalyst deployment, behind an interface and on the tech-debt register. For anything new, or where modern Sass or runtime theming is required, skip this package entirely — scssphp/scssphp for a PHP-side pipeline, Vite/Dart Sass for everything else, and CSS custom properties for white-label theming.