Base Bundle Laravel Package

Product Decisions This Supports

Primary decision it supports: a "no" on adoption, with a salvageable checklist. This package is not a Laravel package — it is a Symfony 2.x bundle (HTML5/Twig boilerplate with added security and quality tooling). That framing alone determines most of the decisions below.

• Build vs. buy vs. reference. The realistic answer is neither build nor buy — treat it as a reference artifact. Its scope (secure-by-default scaffolding + quality gates baked into the base project) is a legitimate pattern worth copying conceptually into our own starter kit, but not worth depending on.
• Roadmap input: baseline hardening as a milestone. The package's premise — security headers, Twig auto-escaping defaults, CSRF, plus static analysis / coding-standard / CI gates — maps cleanly onto a "Secure & Quality Baseline" epic for any greenfield service. A PM can use the described feature list as a requirements sketch for that epic rather than as a dependency.
• Architecture decision: batteries-included base bundle vs. composable packages. This project represents the "one bundle does scaffolding + security + quality" approach. Our stack (Laravel) favors composition: framework skeleton + discrete, maintained packages for CSP/headers, plus Larastan/Pint/PHPStan in CI. Decide explicitly; don't drift into a monolith scaffold by accident.
• Vendor/dependency governance. With 0 stars, 0 dependents, a score of 0, and no visible release activity, this is a useful test case for our dependency intake policy: it should fail on health signals alone, before anyone evaluates the code.
• Not supported by this package: any decision to add a runtime dependency, any Laravel service provider integration, any assumption of maintained security patches. The "Add security tools" claim is unverifiable from the description — a security claim without documentation is an audit liability, not an asset.

When to Consider This Package

Consider it only under a narrow, largely historical set of conditions:

• You are maintaining an existing Symfony 2.x application (PHP 5.x/7.0-era) that already vendors this bundle, and you need to understand or preserve its conventions during a migration-out.
• You need a historical example of how Symfony 2 boilerplate bundles structured Twig templates, security configuration, and quality tooling — e.g., informing a migration mapping document.
• You want a reading list, not a dependency: skim it for ideas, then discard the code.

Do not consider it if any of the following is true — which in practice is always:

• Your target is Laravel. A Symfony bundle's service container, config tree, and bundle registration are structurally incompatible; "adoption" would mean a rewrite, at which point you are not adopting anything.
• You need a maintained dependency: Symfony 2 has been end-of-life for years, meaning no security patches upstream, and this bundle shows no signals of active maintenance (no stars, no dependents, no visible release cadence).
• You require documented, auditable security controls. "Add security tools" is a marketing line, not a spec.
• You need support, SLAs, or a community to escalate to. There is none.

Look instead to (Laravel equivalents of the same intent): laravel/laravel or Breeze/Jetstream for scaffolding; spatie/laravel-csp or a small custom middleware for security headers; larastan/larastan, phpstan/phpstan, laravel/pint, and rector/rector wired into CI for the quality half. For teams still on Symfony, the modern equivalents are symfony/skeleton, symfony/security-bundle, and MakerBundle.

How to Pitch It (Stakeholders)

To executives (one paragraph): We evaluated phil/base-bundle, a Symfony 2 bundle that bundles HTML5/Twig scaffolding with security and code-quality tooling. Recommendation: do not adopt. It targets an end-of-life framework, is not compatible with our Laravel stack, and shows zero adoption signals (no stars, no dependents, no release activity) — meaning no maintainer, no security patching, and no support path. The idea behind it is sound and we already have better-maintained equivalents; the artifact carries risk with no offsetting benefit. Cost to adopt: a rewrite. Cost to ignore: none.

To engineering: Treat this as a design reference only, not a dependency. Two things are worth extracting: (1) the checklist of what a secure-by-default scaffold should include — auto-escaping on by default, CSRF protection, security headers, and quality gates enforced in CI rather than by convention; and (2) the reminder that scaffolding and quality tooling belong in the project template so teams inherit them instead of re-litigating them per service. We will implement the equivalent in our Laravel starter via larastan, pint, and a headers/CSP middleware. Flag for the dependency-governance review: this package fails intake on framework mismatch and maintenance signals alone, and its security claims are undocumented — do not vendor it into any repository, including as a copy-paste source, without a license and provenance check.