Sasso Shopware Compiler Laravel Package

Getting Started

Install with Composer:

composer require shyim/sasso-shopware-compiler

Where to look first: the bundle class Shyim\SassoCompiler\SassoCompilerBundle, then config/bundles.php, then the upstream release notes (0.3.0 is the current naming contract). There is no Laravel service provider or Artisan surface here — this is a Symfony/Shopware bundle, so the integration point is the Symfony kernel, not config/app.php.

First use case: getting the compiler wired into a bootable kernel so SCSS/Sasso compilation runs as part of the app. On a Symfony Flex project, composer require is the entire install — Flex identifies the bundle from the package name and registers it without a published recipe. On a Shopware project (not a Flex app by default), register it manually:

// config/bundles.php
Shyim\SassoCompiler\SassoCompilerBundle::class => ['all' => true],

If you are upgrading from 0.1.0 (the Shopware-plugin era), uninstall the plugin before touching Composer — see the 0.2.0 notes.

Implementation Patterns

Flex-first install. Let Flex do the work: add the package, then verify the bundle landed in config/bundles.php before writing any config. Treat the generated entry as a starting point you can commit, not something to hand-maintain.

Explicit registration for non-Flex apps. Shopware projects should register the bundle manually as above. Keep this in config/bundles.php under the ['all' => true] environment set unless you deliberately want it only in dev.

Pin the major/minor in composer.json while 0.x lasts. Releases in the 0.x range routinely ship breaking changes (0.3.0 renames a class), so "shyim/sasso-shopware-compiler": "^0.3" is safer than * or dev-main.

Verify registration in CI, not just locally. A cheap smoke test is booting the kernel (bin/console about or a minimal Kernel::boot()) — a missing bundle class fails exactly there and nowhere earlier.

Upgrade flow for the 0.3.0 rename: bump the constraint, update config/bundles.php in the same commit, run bin/console cache:clear, then boot. Keeping the diff to those two files makes the breaking change reviewable.

Gotchas and Tips

• Breaking class rename. Shyim\SassoCompiler\ShyimSassoCompiler no longer exists. Any config/bundles.php still referencing it causes a fatal "class not found" at boot — the kernel never gets far enough to give you a helpful error.
• Flex identification is a naming heuristic, not reflection. SymfonyBundle::extractClassNames() takes the last segment of the PSR-4 prefix and appends Bundle, then checks the file exists. For Shyim\SassoCompiler\ that is SassoCompilerBundle. The old ShyimSassoCompiler name could never match, so Flex silently registered nothing — no warning, no error, just a bundle that wasn't there.
• The old name was a Shopware convention (plugin class matching the directory) that stopped applying once this became a bundle. If you are porting code or docs from 0.1.x, don't carry that pattern forward.
• Silent failure mode: if auto-registration seems not to happen, check config/bundles.php first. Flex does not complain when the heuristic misses.
• Cache is the usual red herring. After the rename, bin/console cache:clear (and clearing var/cache) resolves most "still seeing the old class" symptoms; a stale bootstrap/cache-style artifact is not the issue here since this isn't Laravel.
• Don't reach for Laravel idioms. No package auto-discovery, no ServiceProvider, no artisan vendor:publish. Configuration is Symfony bundle config (config/packages/*.yaml) if and when the bundle exposes any.
• Extension point: the bundle class itself is the seam — subclassing or decorating it is possible, but any new name must still satisfy Flex's <LastPsr4Segment>Bundle rule to stay auto-registerable.