Symfony Static Dumper Laravel Package

Product Decisions This Supports

• Delivery architecture: dynamic vs static vs hybrid. Determines whether a PHP app can be pre-rendered to HTML at build time and served from a CDN/object store, with genuinely dynamic behavior isolated behind APIs or edge functions.
• Hosting and cost model. Static output removes PHP-FPM and database work from the read path; enables cheap object-storage/CDN hosting. Directly informs the "what are we paying for runtime on pages nobody writes to?" conversation.
• Build vs buy vs adopt. Serves as a concrete reference architecture for "export an existing PHP app to static files" — useful for scoping a spike or a 2–4 week internal build instead of a vague "we could make it static" proposal.
• Roadmap sequencing for read-heavy surfaces. Good fit for marketing pages, docs, blog, changelog, help center, landing pages — high read-to-write ratio, low personalization.
• Stack consolidation. For a Symfony shop, this is the native static-export option (Laravel analogue: spatie/laravel-export; maintained Symfony alternative: Stenope). Supports the "one framework, one build pipeline" argument.
• Decommissioning old surfaces. Tells you whether a legacy Symfony subsite can be frozen to static, its runtime retired, and its content still served — a real cost-removal lever.

Explicitly not supported: authenticated areas, personalized pages, real-time data, multi-step forms, CSRF-protected POST flows, anything depending on server-side session state.

When to Consider This Package

Consider it — as reference material, not as a dependency:

• You already run Symfony and want to see what a static export of the current app actually looks like before committing.
• Your routes are GET-only, cacheable, session-free, and you can enumerate every URL (sitemap, route list, or DB query).
• You need a timeboxed spike to size the effort before choosing Stenope, spatie/laravel-export, or an in-house dumper.
• You want working code for the crawl → request → render → write loop rather than designing it from scratch.
• You're doing a deprecation/exit analysis and need to know what functionality would have to be replaced.

Look elsewhere — or stop:

• Any production dependency. The repo lives under deprecated-packages; score 0, 0 dependents, no visible maintenance. No security patches, no Symfony LTS guarantees, no issue triage. Inheriting this means inheriting the maintenance.
• Newer Symfony/HttpKernel versions — verify version constraints early and expect breakage. Assume it targets an older Symfony.
• Laravel stacks → spatie/laravel-export (maintained, framework-native).
• Symfony stacks wanting something supported → Stenope.
• You need incremental builds, ISR, image optimization, asset hashing, edge middleware, or preview/draft workflows — use a platform that ships those (Astro, Next.js, Eleventy, Hugo) rather than bolting them onto a dumper.
• Auth, CSRF forms, live data — static export is the wrong lever; look at reverse-proxy caching, SSR caching, or edge rendering instead.

Due-diligence checklist before any go-ahead: last release date; supported Symfony range; open issues/PRs; license; how it enumerates URLs; handling of redirects, 404s, and 500s; asset copying step; whether output is byte-deterministic across runs; whether it can leak secrets or drafts into HTML.

How to Pitch It (Stakeholders)

For executives (one paragraph): "Static export" means taking our existing PHP application and writing every page out as plain HTML at build time, then serving those files from a CDN — no PHP and no database in the request path. It typically reduces hosting cost, improves page load, and shrinks attack surface. The package under review is a Symfony tool that does exactly this, but it is officially deprecated and effectively unmaintained (0 dependents, no active release signal). My recommendation is not to adopt it as a dependency. Instead, treat it as a reference design and either use a maintained alternative — Stenope for Symfony, spatie/laravel-export for Laravel — or budget a short internal spike. Indicative effort: 3–5 days to validate on a subset of routes; 2–4 weeks to productionize with build pipeline, cache invalidation, and draft-preview handling.

For engineering:

• How it works: boots the Symfony kernel, iterates a supplied URL list, issues an internal Request per URL, captures the Response, and writes the body to output/<path>/index.html. No magic — which is also the entire risk surface.
• Watch for: non-determinism (timestamps, random IDs, CSRF tokens, cache-busting query strings), redirect/404 handling, absolute vs relative URLs, the asset/Webpack copy step, completeness of route enumeration, and build time scaling linearly with page count.
• Deprecation means we own it. If we adopt the pattern, plan on roughly 300–600 LOC to own and test — smaller than it sounds, but it is ours forever.
• Spike success criteria: N representative routes export byte-identical on re-run; no secrets or unpublished content in output; build under an agreed time budget; output deployable to a CDN with no server-side rewrite rules.

The ask: approve a one-week timeboxed spike on the marketing/docs routes against a maintained alternative, with a go/no-go decision on retiring the PHP runtime for those surfaces.