Node Sass Laravel Package

Product Decisions This Supports

• Asset-pipeline modernization / technical-debt prioritization. node-sass is a native-binding wrapper around libsass, which the Sass team has deprecated in favor of Dart Sass. An archived repo with a 2023 final release is a concrete, datable "we are on a dead-end dependency" data point for the roadmap — useful for arguing a migration ticket up the backlog with evidence rather than vibes.
• Framework upgrade gating. In Laravel specifically, this surfaces through the frontend build chain (package.json → Laravel Mix → node-sass), not composer.json. Any decision to move to Mix 6+/Vite, or to bump Node LTS, is blocked until this is replaced. Use it to sequence Node/Laravel upgrades correctly instead of discovering the break mid-sprint.
• Build-vs-buy vs. build-vs-replace. The buy question is settled: it's free (MIT) and already in the tree. The real decision is replace with Dart Sass (sass) now vs. pin and defer. Quantify: prebuilt binary fetch failures behind corporate proxies, compile times, and CI flake rate are the cost of deferring.
• Supply-chain and dependency-governance scope decision. This is a PM-visible gap: a Node-native dependency carrying C++ compilation and post-install binary downloads will be missed by PHP-side SCA/composer audit tooling. This package is a forcing function for deciding whether frontend/transitive dependencies get their own inventory and scanning policy.
• Use cases it still legitimately serves: legacy themes/apps pinned to older Node versions, lockfile-frozen maintenance branches, and air-gapped environments with prebuilt binaries already cached. Not a candidate for new surfaces.
• Deprecation communications. PM owns the "no new usage" rule and the sunset date; engineering owns the swap. This package is the artifact that makes that policy enforceable in review.

When to Consider This Package

Consider retaining it (short-term, with a dated exit) when:

• You maintain a legacy Laravel app or theme on Laravel Mix 5 or earlier, with a working, committed lockfile and cached binaries.
• The app is on an older Node LTS that node-sass's final binaries still match, and no Node upgrade is planned this cycle.
• SCSS output is stable and untested-by-CSS-tests; the migration risk is real and the current build is green.
• You need libsass-specific output parity during a freeze (e.g., mid-release, pre-audit).

Look elsewhere immediately when:

• Any new project. Use sass (Dart Sass). Non-negotiable — the repo is archived, so there are no security patches, no Node compatibility work, and no bug fixes, ever.
• You're on Node 18+/20+ or planning to be — native module rebuilds against new ABI versions are the classic failure mode, and there is no upstream to fix it.
• You need modern Sass features: the module system (@use/@forward), math.div, modern color functions, or anything post-libsass.
• You're adopting Vite (Laravel's current default) — it expects Dart Sass.
• Your org requires maintained dependencies for compliance, SBOM, or vulnerability SLAs. Archived + native bindings + install-time binary download is a poor answer to any of those questions.
• CI stability matters: repeated node-gyp/binary-fetch failures are a recurring tax that no amount of pinning fully removes.

PM framing on the score: 8.4k stars reflect historical adoption, not current health. Treat stars as a legacy-installed-base signal only; the "opportunity: 17.5" reading is consistent with "migrate off, don't invest in."

How to Pitch It (Stakeholders)

One-liner for executives: This isn't a product feature — it's a dead build-tool dependency sitting inside our frontend asset pipeline. It costs us nothing in license fees and everything in reliability, and replacing it is a small, bounded, low-risk engineering task with a clear deadline attached to our next Node and Laravel upgrades.

The ask: Approve a scoped migration from node-sass/libsass to Dart Sass (sass), plus a policy item that frontend dependencies are in scope for dependency scanning.

Why now:

• Upstream is archived; the last release was May 2023. No security patches, no Node compatibility fixes.
• It depends on libsass, which is deprecated — we are building on an end-of-life compiler.
• It requires native compilation and install-time binary downloads, which is the single most common cause of "works on my machine" and CI flake, and it silently breaks on Node upgrades.
• It blocks or complicates the Node LTS and Laravel/Vite upgrade paths we already want.

Why the risk is low: MIT-licensed, drop-in replacement API for standard SCSS; the change is mostly package.json, lockfile, and build config. Real risk is confined to CSS output differences, which a visual regression pass on key templates covers.

Why it's cheap to defer and expensive to forget: Deferring is free until the next Node upgrade, at which point it becomes an unplanned blocker on someone else's deadline. A dated ticket now converts a surprise into a scheduled task.

What we get: Faster, more reproducible builds; unblocked Node and framework upgrades; access to the modern Sass module system; removal of a native toolchain from every developer's and CI runner's setup; and a dependency inventory that doesn't have a blind spot on the frontend.

Decision requested: Approve the migration ticket for the next maintenance window, and approve the governance rule that package.json dependencies are included in our dependency-review process.