graham-campbell/viewer
Graham Campbell's Viewer is a PHP package for rendering views with a simple, flexible API. It integrates with Laravel and provides a clean way to manage view rendering, making it easy to add reusable templates and view logic to your applications.
Portfolio triage: which inherited services get modernization funding. This is not a feature line item — it is a signal. A package that describes itself as a "view workaround for Laravel 4.1" is evidence that the service containing it has not been actively developed in roughly a decade. Laravel 4.1 stopped receiving security patches in 2015. Use its presence as an input to prioritization: how does this part of the estate rank against competing modernization work? It informs that ranking; it does not constitute the work itself.
Sizing and framing the framework-upgrade business case. There is really one open question here — the cost and timing of deletion — and that resolves into the cost of the host application's framework upgrade. Treat this package as a concrete, quantified line in that estimate, not as a standalone project. Any ticket scoped as "fix/upgrade/extend the viewer package" is a mis-scoped proxy for the upgrade.
Setting dependency exit criteria for future "buy" decisions. Graham Campbell's packages were a reasonable purchase in the Laravel 4/5 era: small, focused, maintained. This one now lives in an explicitly GrahamDeprecated organization with a 0.3 health score, zero stars, and zero dependents. The reusable lesson is that a dependency does not leave your composer.json when its maintainer leaves — you inherit the removal cost years later. Use it as the reference case when defining, for current decisions, who owns removal and by when.
Due-diligence escalation. The published description advertises a file browser — disks, MIME types, inline previews, download responses — which does not match the repository name, the "view workaround" tagline, or a changelog whose only substance is PHP 5.6/HHVM compatibility. A description that overstates capability relative to the artifact is itself grounds to distrust any "it gives us X" claim made about it in a planning meeting. Verify against src/ before crediting it with any capability.
Legitimate (non-roadmap) uses: (a) forensics — explaining to an auditor or acquirer why an unsupported shim sits in an inherited application; (b) dependency-risk inventory — a line item with a named owner and target removal date; (c) upgrade estimation — one input to the Laravel 4.1 exit plan. None of these are product features and none justify roadmap capacity.
Budget allocation. Zero capacity for extension, integration, or porting. If a team proposes work on this package, redirect the conversation to the framework upgrade business case.
Consider it only in two narrow situations:
src/ first; there is almost certainly nothing to evaluate, and the mechanism (container rebind vs. view-factory replacement) determines the removal effort.Look elsewhere — specifically, to the framework — when:
View::addLocation, View::addNamespace, view composers, and Blade components cover everything this shim was patching. There is nothing to build with here.Weigh the release carefully. v0.2.0-alpha is a pre-1.0 alpha cut after deprecation, containing no functional change: it raises the PHP floor to 5.6 (EOL December 2018) and adds HHVM compatibility (a runtime that dropped PHP support in 2018). A headline capability of "runs on two retired runtimes" tells you where the project's center of gravity sits. A post-deprecation alpha is a worse signal than silence, because it invites a false "actively maintained" reading. The unspecified composer.json tweaks are the only item with operational teeth: an unexamined constraint change can move what resolves in your lockfile, with no upstream to patch it.
Decision rule: absent a Laravel 4.1 runtime you cannot change, this fails the bar for adoption. If you are on Laravel 4.1, the priority is the framework upgrade, not this package.
For executives: This is a small, abandoned helper library pinned to a framework version that stopped receiving security updates around 2015. It has no maintainer, no known users, no upgrade path, and its most recent release is an alpha whose only content is compatibility with two retired runtimes. In isolation it is not a material risk and not worth investment. The risk is the surrounding application that still depends on it. Recommendation: approve no new spend; fold removal into the next platform upgrade and treat the dependency as evidence for why that upgrade should be scheduled and funded.
For engineering: Treat as deprecated by default. Confirm via code search which Laravel 4.1 view behavior the host application actually relies on — path ordering, namespace resolution, or cascade fallback — and whether the package patches by container rebinding (removable with a config edit), supplies a custom finder (portable to native config), or replaces the view factory (a fork you now own). Record the currently pinned version and commit hash before anything moves; diff the PHP requirement, illuminate/* ranges, and PSR-4 mappings before accepting the alpha tag, and do not let a routine composer update float you onto it. Write characterization tests over view resolution, then delete the package as part of a framework upgrade. If the upgrade is genuinely blocked, vendor the source into application namespace, pin it to a commit, and assign a named internal owner with a removal ticket. The first option is strongly preferred. Do not extend it — adding a hook or subclassing the shim is the trap; the correct move is always replacement.
For product: No user-facing capability depends on this package. It should not appear in a roadmap review except as evidence that the area of the codebase containing it needs modernization. The dominant cost is organizational, not technical: a package this small can absorb disproportionate engineering time in archaeology, and that cost grows with team turnover rather than with traffic. The product-relevant question is not "what does this do for users," but "what else is in this service that we have not funded for ten years, and what is our exposure if it breaks?"
How can I help you explore Laravel packages today?