Last Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy vs. borrow for static generation. This package answers a narrow question — "can we pre-render pages from an existing Symfony app without adding a second build system?" — and it answers it cheaply. With ~0 dependents and low stars, it is still best treated as a reference implementation to spike against, not a dependency to adopt. The v1.1 release does not change the shape of that answer.
• Roadmap sequencing for legacy Symfony estates. The original release (August 2018) puts it squarely in the Symfony 4.1–4.3 window. Symfony 4.4 reached end of life in November 2023. A v1.1 that adds a CLI flag is not a framework-version bump — there is no evidence the package has been modernized for Symfony 5/6/7 or PHP 8. If this package is on the table, the real roadmap item is not "add static generation" — it is "we are running an EOL framework and need a migration plan." Use this as evidence in that conversation, not as the solution.
• Stack-fit gate. Despite being surfaced as a "Laravel/PHP package," this is a Symfony 4 bundle, not a Laravel package. It will not install into a Laravel app without meaningful porting work. The first product decision it supports is therefore a screening decision: reject for any Laravel roadmap item; consider only for Symfony 4.x.
• Hybrid static/dynamic architecture. Where it is relevant, it supports the use case of serving marketing pages, docs, and blog content from a CDN while keeping authenticated/app routes dynamic — a real cost and performance lever if the content surface is a small fraction of total traffic.
• The high opportunity score (0.92) against a near-zero adoption score (0.145) is itself the signal. A gap exists — Symfony-native static export without leaving the framework — but this package is not filling it. That reads as "underserved niche," which is a make decision (internal tool, or evaluate Spress/Sculpin successors), not a buy decision.

When to Consider This Package

Consider it only when all of the following hold:

• The codebase is Symfony 4.1–4.3 and will not move to 5.x/6.x/7.x within the planning horizon.
• The static surface is small and low-churn (docs, landing pages, a blog) — not the core product.
• You are willing to vendor or fork the source rather than depend on Packagist. One minor release after a multi-year gap is a hobby-maintenance cadence, not a support contract; do not build a delivery commitment on it.
• No PHP 8.x requirement. A 2018-era Symfony 4 bundle predates PHP 8 by two years; expect deprecation noise at minimum and hard failures at worst. v1.1 ships a CLI ergonomics change, not a compatibility pass.
• The cost of a 1–2 sprint spike is cheaper than the cost of evaluating a maintained alternative — i.e., you want a proof of concept, not a platform.

Look elsewhere when:

• You are on Laravel. This is a hard no. The bundle hooks into Symfony's kernel and DI container. Porting cost likely exceeds rebuilding on Tighten Jigsaw, Spatie's static-site tooling, or an Astro/Eleventy front end.
• You need security patching or vendor support. Near-zero dependents and a single flag-level release since 2018 mean no one is watching CVEs in this dependency tree.
• You need incremental builds, asset pipelines, or modern DX — expect to build these yourself. v1.1's overwrite warning + --force flag is a guardrail around a destructive default, not a build-system feature; the lack of a safe-by-default output directory until now is itself a maturity signal.
• A maintained alternative fits: Jigsaw (Laravel/Blade-native), Sculpin or Spress (PHP, more active historically), or a JS SSG if the team already has front-end tooling.
• The static output is the product rather than a side channel — then the abandonment risk is existential, not incidental.

How to Pitch It (Stakeholders)

For executives (one paragraph): We evaluated fw/last-bundle, a static site generator for Symfony 4. A new v1.1 has appeared, but the substance is a safety warning before overwriting the output folder plus a flag to force it — housekeeping, not a revival. The package remains effectively unmaintained: one minor release after a gap of several years, no known downstream users, and still targeting a framework version that reached end of life in late 2023. I do not recommend adopting it as a dependency. I do recommend a two-week spike to validate whether static pre-rendering of our content pages is worth pursuing at all; if it is, we build or buy a maintained solution rather than inherit this one. Cost of the spike is low; cost of adopting an abandoned package into an EOL framework is not.

For engineering:

• It is not a Laravel package. Treat any roadmap item scoped against Laravel as blocked on stack fit alone.
• If we do spike it: vendor the code, pin it, and budget for PHP 8 compatibility work. Do not add it to composer.json as a normal requirement.
• The v1.1 change tells us two things: (1) the default behavior previously clobbered dist/ with no prompt, which is a data-loss footgun to verify before running it anywhere near real output; (2) --force is an opt-out of a guardrail, not an opt-in to a safe default — check whether --force is required in CI or whether non-interactive runs now fail on the prompt. Treat that as a concrete task in the spike, not a documentation detail.
• Success criteria for the spike should be measured, not vibes: build time for N pages, percentage of routes that can be made static, CDN cache-hit ratio, and the delta in p95 TTFB versus dynamic rendering. If the spike cannot clear those bars in two weeks, the answer is no.
• The strategic read is unchanged: the need is real (high opportunity signal) and the supply is thin (low adoption signal, one minor release). That is a build-or-buy conversation about static generation on our stack — not a package-selection conversation about this one.