overlook/foundation
A foundational toolkit for Laravel applications, bundling core utilities, conventions, and service providers into a consistent base layer. Streamlines new project setup and gives PHP packages a shared starting point for building maintainable apps.
Architecture fit. overlook/foundation is not a feature library — it is a codified set of application conventions ("the conventions Overlook Innovations applies to every application it builds"). That positions it as a baseline/preset layer for Laravel: expect a Composer package with Laravel auto-discovery (extra.laravel.providers), opinionated config defaults, possibly Artisan scaffolding commands, and pinned tooling (Pint, PHPStan/Larastan, Pest/PHPUnit, CI templates). For a TPM, the architectural value is standardisation leverage: one place to encode directory layout, error handling, logging, and quality gates across a portfolio of Laravel services. It fits well only if we are prepared to adopt its opinions wholesale; it fits poorly as a cherry-picked utility.
Integration feasibility. Mechanically low friction — a single composer require in a Laravel app, with config publishing and provider registration. The real feasibility question is validation, not effort: 0 stars, 0 dependents, and a composite score of ~15.8 mean there is no external evidence that this package has ever run in a production codebase outside its author's. The listed last release (2026-08-13) should be verified against the actual tag history — an anomalous date is a signal to check release hygiene, changelog discipline, and whether tags map to tested commits. Integration is feasible in days; trusting it requires a source audit first.
Technical risk. High, concentrated in four areas:
illuminate/* and PHP version ranges; a narrow matrix will block upgrades and pin us to a Laravel major we may want to leave.Key questions.
Stack fit. Assumes a conventional modern Laravel stack: PHP 8.1+, Composer 2, Laravel 10/11/12, Pint + PHPStan/Larastan + Pest in CI. If our apps already converge on those tools, the package is a consolidating layer; if we run heterogeneous tooling or older Laravel majors, adoption cost rises sharply and per-app exceptions will erode the standard.
Migration path. Do not retrofit existing applications first. Sequence: audit → sandbox spike → greenfield pilot → brownfield single-app trial → template rollout. For existing apps, install on a branch, run vendor:publish and diff every published config against current values, then run the full test suite plus config:cache and route:cache to surface boot-time side effects. Keep the dependency pinned to an exact version until we have our own regression suite around it.
Compatibility. Concrete checks: composer why-not against our Laravel/PHP constraints; collision scan for duplicate service providers and conflicting config keys; verify our existing Pint/PHPStan configs merge rather than fight; confirm it does not re-register things we already customise (exception rendering, logger channels, middleware order). Where it conflicts, prefer disabling our local customisation rather than forking — otherwise we get the worst of both.
Sequencing. (1) Source audit and licence review — 1–2 days. (2) ADR documenting what we adopt, what we override, and what we deliberately ignore. (3) Greenfield pilot on a low-risk new service — 1 sprint. (4) Extract a "new app" template repo that consumes the package, so future projects start compliant by default. (5) Only then trial on one brownfield app, with a documented rollback (revert commit + composer remove). (6) Internal fork under our org if the audit passes but upstream velocity is a concern — pin, mirror, and cherry-pick.
Maintenance. This is the dominant cost. With zero dependents, we are effectively the only production consumer, which means we find the bugs. Budget for an internal owner (roughly 10–15% of one engineer during adoption, tapering to a few hours per month) to track upstream, test new Laravel majors, and manage the fork. Treat upstream as an input, not a dependency: vendor or fork with a pinned tag so an upstream force-push or deletion cannot break our builds.
Support. No community, no SLA, no Stack Overflow corpus. Support is entirely internal: our ADR plus a short internal README describing what the package changes and why. That documentation is non-negotiable — a conventions package whose conventions are undocumented is a trap for the next team.
Scaling. Runtime scaling impact is negligible; these packages are glue and config, not hot paths. The scaling risk is organisational: as headcount and service count grow, a single external opinion becomes a governance bottleneck. Mitigate by owning the fork and making changes through an internal PR process, so conventions evolve with the org rather than at the vendor's pace.
Failure modes.
phpunit but fail under config:cache in production.Each maps to a control: pinned versions, cache-warmed CI, a documented exit plan (fork), and periodic conformance checks.
Ramp-up. Positive for onboarding — new engineers inherit layout, tooling, and quality gates on day one instead of learning three codebases' idiosyncrasies. Expect ~1–2 days for engineers familiar with Laravel to absorb the opinionated parts, versus ~3–5 days of TPM/lead time upfront on audit, ADR, and template creation. The net is favourable if and only if the audit passes.
TPM recommendation. Do not adopt on the strength of the package's own claims. Commission a short, time-boxed audit (2 days) against the six key questions. If it passes, adopt as an internal, pinned, forked baseline behind a template repo — and treat the opportunity score (~47) as a signal that the idea of a standardised Laravel foundation is worth more than this specific implementation, which we may ultimately rebuild in-house in a fraction of the time it would take to inherit its unknowns.
How can I help you explore Laravel packages today?