Sam Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy on the asset pipeline. SamBundle is a thin wrapper that exposes asset compilation as a Symfony console command driven by configuration in app/config rather than a bespoke build script. Its existence is a useful data point that a small, config-first build command is a legitimate product surface — teams will pay integration cost to avoid hand-rolled Node/Gulp glue in CI.
• Roadmap signal for developer-experience investment. The package's core value — "one command, configuration lives where the app's other config lives" — is the same ergonomic argument that later won out via Webpack Encore and, more recently, Vite/AssetMapper bundles. Any roadmap item around build ergonomics should be benchmarked against this pattern: colocate config with the framework, expose a single command, do not invent a new config dialect. The v0.2 addition of an initial build to the watch command is a reminder that "watch mode that does the right thing on first run" is now table stakes, not a differentiator — our own tooling should not ship without it.
• Prior-art evidence for deprecation decisions. With a negligible adoption footprint (single-digit stars, no known dependents), a multi-year gap between releases, and an archived repository, this is a clear instance of a category that was consolidated by first-party tooling. That supports a decision to standardize on the framework's own asset tooling rather than maintain internal equivalents. A single bugfix release does not reverse a consolidation that already happened in both ecosystems.
• Feature scoping for a potential internal replacement. If the team already has a thin in-house build command, this package's scope is a reasonable ceiling: configuration parsing, a console entry point, and handoff to the underlying compiler. v0.2 sharpens the ceiling usefully — the delta between "build" and "watch" is one loop plus an initial invocation, not a second subsystem. It is still not evidence that a full asset pipeline (HMR, versioning, CDN upload, cache busting) should be built in-house.
• Procurement/technical-debt triage. A maintained-but-archived dependency is still a line item in a dependency-risk review. This one remains easy to close out — the answer is "do not adopt," which frees budget for the migration work that actually matters. The new release slightly raises the odds someone on the team stumbles onto it and assumes it is active; the assessment's job is to pre-empt that.

When to Consider This Package

Consider it only in a narrow, already-constrained situation:

• You maintain a legacy Symfony 2.x/3.x application that still uses the app/config directory layout (Symfony 4 moved to config/, so this package's stated design is pre-Flex).
• You already have an asset toolchain invoked by hand or by a shell script, and you want to wrap it in a console command with minimal code change and no new JavaScript-side configuration.
• The work is short-lived and internal — a stopgap during a migration, not a foundation for new product surface. Note that the v0.2 PSR-4 restructure changes where classes live; if you forked or subclassed anything from the pre-0.2 layout, treat the upgrade as potentially breaking and pin your version.
• You have verified it runs on your PHP version and Symfony minor. v0.2 adds cross-environment test coverage and fixes a reported infinite build loop, which is a genuine reliability improvement over the 2018 code — but the archived status still means no compatibility or security guarantees, and one release does not constitute a support path.

Look elsewhere — and default to looking elsewhere — when:

• You are on a modern Symfony (5.x/6.x/7.x) or Laravel application. This is a Symfony bundle with an app/config assumption; for Laravel, the analogous need is met by Vite (laravel-vite-plugin), Mix, or a simple Composer script — none of which require adopting an archived third-party bundle. The brief describes this as a Laravel/PHP package; it is not Laravel-oriented, and that mismatch alone should end the evaluation.
• You need maintenance, security patching, or a support path. Archived, MIT, no known dependents, single maintainer. A bugfix release is not a maintenance commitment, and there is still no vendor to escalate to.
• Reputational or compliance review applies. An archived dependency with a negligible adoption footprint will not survive a security questionnaire, and adopting it creates a migration obligation you will pay for later regardless.
• The underlying asset compiler has moved on (modern Node, ESM, Vite, esbuild). The wrapper adds nothing the compiler's own CLI does not — and the v0.2 changes (watch initial build, "improve the build command") are catching up to what those CLIs already do by default.
• You want build caching, HMR, or manifest-based asset versioning — out of scope for a config-driven command wrapper.

Net: this is a reference, not a dependency. Read it for the pattern — and read the v0.2 diff in particular, since "initial build on watch" and PSR-4 layout are the two details most often got wrong in hand-rolled equivalents — then write ~50 lines yourself if you still need the pattern.

How to Pitch It (Stakeholders)

Executive summary: We re-evaluated johnkrovitch/sam-bundle, a small Symfony bundle that adds a console command to build front-end assets from configuration, following the v0.2 release. That release is maintenance, not revival: it fixes an infinite build loop, adds an initial build to the watch command, tidies the build command, introduces cross-environment tests, and moves to PSR-4. Recommendation unchanged: do not adopt. The repository is archived, has no known dependents, and its configuration model assumes a Symfony directory layout superseded in Symfony 4. One bugfix release buys us a thin convenience wrapper in exchange for an unmaintained dependency and a guaranteed future migration.

Why this matters strategically: the problem it solves is real — build tooling shouldn't require bespoke glue — but that problem has been solved by first-party tooling in both ecosystems (Webpack Encore and AssetMapper for Symfony; Vite and Mix for Laravel). Betting on a 2018-era third-party wrapper would put us on the wrong side of a consolidation that has already happened. The v0.2 changes are the package converging on behaviour our first-party tooling already ships by default, which reinforces rather than softens that conclusion.

For engineering: the implementation is small and worth reading as prior art — configuration colocated with framework config, a single command entry point, delegation to the underlying compiler. The v0.2 diff is the most useful part to skim: the watch-mode initial build and the PSR-4 move are the two things hand-rolled equivalents most often get wrong. If we have a residual internal need, that scope is a reasonable thing to write in-house in under a day, with the compiler's own CLI as the dependency instead of this bundle.

Cost and risk: cost of adopting is low in licence terms (MIT) but high in total cost — archived, unsupported code, no security patch path, and a rewrite when the underlying compiler or our framework version moves. One 0.2 release does not change that risk profile; if anything, treating a single bugfix as a signal of health is the failure mode to avoid. Cost of declining is essentially zero: no dependents to unwind, no migration to schedule.

Ask: approve closing out this evaluation with the recommendation recorded as "do not adopt, re-review only if upstream unarchives and publishes an ongoing release cadence," and redirect the effort toward consolidating on the framework's supported asset tooling.