Sass Bundle Laravel Package

Product Decisions This Supports

• Frontend toolchain consolidation (build vs. buy vs. drop). This bundle is the enabling piece for a "no Node.js" CSS workflow on Symfony's AssetMapper. If it's credible, it removes a whole build system (Webpack Encore / Vite + npm + lockfiles) from the stack. That's a real roadmap decision, not a technical detail: it changes CI time, container image size, dependency-patch cadence, and the skills you hire for.
• Buy vs. build. The alternative to adopting this is writing your own scssphp/scssphp integration into AssetMapper (a few days of work plus permanent ownership), or standing up a JS build pipeline. Buying here is cheap (MIT, one composer require) and reversible, which makes it a low-risk default.
• Sass is a product commitment, not just a syntax choice. Adopting it means your design tokens, theming, and vendor overrides (Bootstrap, legacy stylesheets) live in .scss. That determines whether a future migration to CSS-native nesting/custom properties is a rewrite or a rename. Sequence this against any planned design-system refresh.
• Use cases where the value is clearest: PHP-heavy teams with no dedicated frontend engineer; internal admin/back-office and B2B apps where the CSS footprint is modest; incremental migration of an existing Sass codebase off Encore; Symfony products where frontend tooling is pure overhead relative to the feature surface.
• Where it shouldn't drive the roadmap: consumer-scale storefronts with large, hot-reloaded SCSS trees, or any product where the design system depends on bleeding-edge Sass features or PostCSS/Tailwind-style processing in the same pass.
• Roadmap dependency to log: this choice couples you to AssetMapper. Note it as a known switching cost against any future "move to Vite" initiative.

When to Consider This Package

Consider it when:

• You're on Symfony 6.4+/7.x with AssetMapper and importmaps already in use (or committed to). Outside that context the bundle brings nothing.
• The team is PHP-first and the current cost of maintaining npm/Node/Encore is a recurring drag you'd like to retire.
• Your Sass compilation is small-to-moderate and happens at build/deploy or cache-warm time — compile performance is tolerable because the compiler is PHP-based (scssphp), not dart-sass.
• You need only mainstream Sass: variables, nesting, @mixin/@include, partials, basic @use. Verify each specifically.
• You want a permissively licensed, actively released bundle (recent release May 2026) rather than a bespoke integration.

Look elsewhere when:

• Sass feature parity matters. PHP Sass implementations historically lag dart-sass on newer syntax and module-system edge cases. Spike against your actual stylesheets before deciding.
• Compile time is on the critical path. Large SCSS trees or high-frequency asset rebuilds will feel the difference versus dart-sass.
• You need first-class HMR, source maps, or a plugin ecosystem (autoprefixer, Tailwind, CSS modules) in the same pipeline — that's Vite/Encore territory.
• Community depth is a procurement criterion. ~44 stars and a narrow maintainer base means limited third-party answers, no commercial support, and real bus-factor exposure. Acceptable for an internal tool; riskier for a platform dependency.
• You are not on AssetMapper, or expect to leave it within a year — the switching cost lands on your team.

Minimum validation before committing (one short spike): compile a representative slice of your real SCSS; measure cold and warm build times; confirm the specific Sass features and vendor libraries you depend on; confirm cache invalidation behaves correctly across deploys.

How to Pitch It (Stakeholders)

For executives — one paragraph: "We can author our stylesheets in Sass without adding Node.js, npm, or a JavaScript build step to our Symfony application. That removes a runtime and a dependency tree from CI and production images, reduces the patch burden and supply-chain surface that comes with npm packages, and lets our existing PHP developers own styling work end to end. It's MIT-licensed, a single Composer dependency, and reversible — if it doesn't fit, uninstalling it costs us a day, not a quarter. It's maintained by SymfonyCasts, a well-known name in the Symfony ecosystem, with a recent release."

For engineering — the substance:

• Standard Symfony bundle wiring into AssetMapper; .scss/.sass compile into the existing asset pipeline, no separate process.
• MIT; recent release (May 2026); authored by a recognized Symfony-ecosystem maintainer — but a young, small-footprint project (~44 stars), so treat it as a dependency you own the risk on, not one a vendor owns for you.
• Known trade-off we accept: PHP-based Sass compilation is slower than dart-sass and may lag on newer Sass syntax. We'll benchmark against our real stylesheet tree and confirm the module features we use (@use, @forward, mixins, functions) before committing.
• Known coupling: this ties the styling workflow to AssetMapper. That's fine while AssetMapper is our direction; it becomes a migration item if we ever move to Vite.
• Ask: a timeboxed spike on a branch — representative SCSS compile, timing measurement, and a feature-parity check — with a go/no-go before we remove any existing build tooling.