Webapp Pack Laravel Package

Product Decisions This Supports

• Default stack for greenfield server-rendered PHP apps. symfony/webapp-pack is the curated "this is what a Symfony web app looks like" bundle set (Twig, forms, security, validator, mailer/notifier, serializer, translation, console, Flex). Adopting it is effectively the decision not to hand-pick 20 bundles, and to inherit Symfony's opinionated baseline instead of inventing one.
• Framework standardization across teams. If the org is deciding between Symfony, Laravel, and bespoke PHP for a portfolio of apps, this pack is the concrete artifact that makes "we're a Symfony shop" real for new services — one composer require, one recipe-managed config/ tree, one onboarding path.
• Build vs. buy for the internal starter kit. The pack defines the boundary of what you get for free vs. what your platform team must add: Docker/devcontainer, CI, static analysis, auth providers, observability, seeding, and your domain-level conventions still belong to an internal acme/app-pack layered on top. This is the classic "fork the default, don't rebuild the default" decision.
• Roadmap sequencing for a back-office/admin surface. Webapp-pack is the right substrate if the near-term roadmap includes authenticated CRUD pages, forms with validation, email notifications, and server-rendered templates — i.e., an internal admin tool or a B2B portal. It is not the substrate for an API-first product, where symfony/skeleton + api-pack (or a lightweight micro-framework) is the cheaper call.
• Vendor and lifecycle risk review. The "package" is a thin Composer metapackage with pinned *-style constraints and a single 2023-12-11 release; the real dependency surface is the underlying Symfony components. Decision: pin the pack version in composer.json, track Symfony minor releases separately, and treat the pack as a convenience pointer rather than a versioned contract.
• Talent and hiring decisions. Choosing the Symfony baseline over Laravel changes the hiring pool, the consultant market, and the ecosystem of packages (e.g., no Eloquent, no Blade, no Artisan). This pack is the smallest, most reversible way to test that bet — a spike costs an afternoon.

Note for the record: this is a Symfony package, not Laravel. The assessment below is written for a generic PHP/Composer decision, but do not schedule it against a Laravel roadmap.

When to Consider This Package

Adopt it when:

• You are starting a new Symfony application that renders HTML — dashboards, portals, admin consoles, marketing-adjacent apps with forms and auth.
• Your team wants the official, community-blessed bundle set and would otherwise spend a sprint arguing about Twig vs. alternatives, which mailer, whether to include Notifier.
• You want Symfony Flex recipe automation — the pack is designed to be installed on top of symfony/skeleton, and Flex wires the config files for you. Manual bundle assembly forfeits that.
• You need a low-commitment starting point: it is a metapackage. Removing it later is a composer remove plus cleanup, not a rewrite.
• You are building an internal starter template and want a maintained upstream to diff against rather than maintaining your own list of bundles from scratch.

Look elsewhere when:

• You are on Laravel. Wrong ecosystem entirely — no service provider compatibility, no Artisan, no Eloquent. Do not put this on a Laravel evaluation slate.
• The product is API-only or headless. Use symfony/skeleton plus symfony/api-pack (or Slim / a Go service). Webapp-pack drags in Twig, forms, and mailer you will not exercise — unused surface area is unused attack surface and unused upgrade cost.
• You need a supported LTS contract. The pack itself carries no support guarantee; only the underlying components do. If procurement needs an SLA, the answer is the Symfony LTS release train, not this repo.
• You need a minimal footprint — serverless/FaaS, tight cold-start or image-size budgets, or a security-sensitive service where every bundled component must be individually justified.
• You already have a heavily customized skeleton. Retrofitting a pack over an existing config/ tree fights Flex and produces recipe conflicts.
• Signals of staleness matter to your governance. Last tagged release is December 2023 and the repo carries 22 stars — but read that correctly: metapackages structurally never accrue stars, and packs are tagged only when the curated list changes. The real health signal is the Symfony release cadence behind it. The 2.0 opportunity score here reflects "thin wrapper, low standalone differentiation," not "abandoned."

How to Pitch It (Stakeholders)

To executives (one paragraph): We can stand up a new PHP web application in hours instead of weeks by adopting the framework vendor's own recommended starting configuration rather than assembling one ourselves. It costs nothing to license, is maintained inside the Symfony project we would already depend on, and — critically — it creates no lock-in: it is a thin list of standard components, so if we change direction we remove one line from a config file. The strategic value is not the package; it is the decision it encodes: one company-wide baseline for how a PHP web app is born, which shortens onboarding, shrinks the review surface for security, and makes hiring and contracting predictable. Expected payoff is in the first two or three projects; treat it as a standard, not a product, and do not fund a roadmap around it.

To engineering leads:

• composer create-project (or composer require symfony/webapp-pack on an existing skeleton) gives you Twig, forms, security, validator, mailer/notifier, serializer, translation, and console with Flex recipes already applied. Persistence is a separate orm-pack decision.
• It is a metapackage — zero runtime code. Your dependency and CVE surface is exactly the underlying Symfony components, which we should already be patching on the normal cadence.
• Pin the pack version; upgrade Symfony minors on your usual schedule. Do not expect pack releases to track component releases.
• Our platform work shifts up a layer: devcontainers, CI, static analysis, auth/SSO integration, observability, and domain conventions belong in an internal pack layered on this one. That is the real build-vs-buy line.
• Pushback to expect and how to answer it: "22 stars, last release 2023" will come up. The answer is that star counts and tag dates are the wrong metrics for a curated list — check the Symfony component release history and the Flex recipe repo instead, and show the upgrade path.

To security and procurement: no proprietary license, no new vendor, no data-processing implications; the review artifact is the transitive Symfony component list, which is the same list you would approve for any Symfony service.