Laravel Pages Laravel Package

Product Decisions This Supports

• Framework upgrade planning (Laravel 11). v0.3.0 explicitly tracks Laravel 11 while dropping Laravel 8. That makes this release the decision point for "can we take the Laravel 11 upgrade without leaving a dependency pinned on an unsupported branch?" Any roadmap item gated on L11 (PHP 8.2+ baseline, new bootstrap/app.php structure, health routing, etc.) can now include this package in scope rather than as an exception.
• Build vs. buy for page/route plumbing. The package replaces the "controller + route entry + view" triad for simple pages with a page-class convention. The buy case is strong because the surface area is small and the alternative is your own internal convention — which you will still have to maintain, document, and onboard people onto.
• Consolidating conventions across teams. If more than one squad has invented its own "BaseController with a __invoke and a view() helper," this is a candidate to standardize on one supported abstraction instead of N homegrown ones.
• Feature scoping for content-heavy or low-logic surfaces. Marketing-adjacent pages, static/legal/help content, internal tools, dashboards, and admin panels with many low-complexity routes are the sweet spot. This supports a "convention for the simple 80%, full controllers for the complex 20%" architecture decision.
• Onboarding cost as a lever. Page-as-class is legible to a mid-level Laravel dev in an afternoon, which lowers the cost of routing new work to junior engineers or contractors.
• Dependency-risk budgeting. A pre-1.0, narrow-scope package is a small line item in a dependency review — but it is a line item, and this release is a good moment to record the version-support posture in your dependency register.

When to Consider This Package

Adopt when:

• You are on Laravel 11 (or can verify 9/10 support in the v0.3.0 support matrix before pinning — the notes only state "add 11, remove 8," so confirm 9/10 status in CI or composer.json before assuming).
• A meaningful share of your routes are thin: resolve a model or two, return a view, maybe apply middleware. That is where the boilerplate savings compound.
• Your team is comfortable with pre-1.0 semantics: minor-version bumps can and do change the support matrix, occasionally without a major-version signal.
• You want an opinionated, small, inspectable dependency — something a senior dev can read end-to-end in a sitting.

Look elsewhere / stay put when:

• You are still on Laravel 8. v0.3.0 removes support; you are on v0.2.2 and effectively frozen. Treat that as a forced roadmap conversation, not a footnote.
• You are on Laravel 9 or 10 and cannot confirm retained support. Pin explicitly and test the upgrade on a branch rather than assuming forward compatibility.
• Your pages carry real domain logic. Authorization policies, transactions, multi-step workflows, and heavy validation belong in controllers/actions; forcing them into a page convention produces an anemic abstraction with a growing pile of exceptions.
• You need contractual stability. A single-maintainer, narrow-scope package is a fine bet for a small team and a poor one for a platform with a multi-year support commitment and no appetite for vendoring a fallback.
• You already have a working internal convention. Migrating working routing code to save a few lines is a net-negative trade unless you are also deleting the homegrown abstraction.
• You need first-class support guarantees, SLAs, or a vendor to call. This is community OSS; treat maintenance continuity as a risk to mitigate (pin versions, keep the usage surface thin, be ready to vendor).

How to Pitch It (Stakeholders)

For executives (one paragraph). This is a small, low-cost library that removes repetitive plumbing for simple pages, letting the team ship straightforward screens faster and with less bespoke code to maintain. The v0.3.0 release is a maintenance milestone: it adds Laravel 11 support and retires Laravel 8 align with the framework's own end-of-life, which means adopting it no longer creates an upgrade blocker. The cost is negligible and the blast radius is small because the package only touches routing for low-complexity pages. The main risk is not technical but organizational — it is a pre-1.0, single-maintainer project, so we should pin versions and keep our usage shallow enough to replace in days, not months. Recommendation: approve for evaluation on the Laravel 11 upgrade, with a 1–2 sprint trial on one non-critical surface before broader standardization.

For engineering (the actual ask). v0.3.0 is a support-matrix release, not a feature release — expect no API surface change, but treat it as a breaking change for anyone on Laravel 8 and an unverified change for 9/10 until CI proves otherwise. Concretely:

1. Bump in a branch, run the full test suite, and confirm the resolved illuminate/* constraints in composer.lock.
2. Verify our floor: if we still support L9/L10 anywhere, confirm this version still does or pin those apps to v0.2.2 and record it.
3. Add the package to the dependency register with an explicit note: pre-1.0, single maintainer, narrow scope, upgrade path is "vendor it."
4. Keep the usage surface thin — page classes for simple routes, standard controllers for anything with policy, transaction, or multi-step logic. If a page class grows a private function chain, that's the signal it should have been a controller.
5. Decide the fallback now, while it's cheap: the abstraction is shallow enough that replacing it means moving route definitions back into routes/web.php. Estimate that cost before you spread it across the codebase.