Installer Laravel Package

Technical Evaluation

Architecture fit

photoncms/installer is a provisioning artifact, not a runtime dependency. For a TPM this reframes the entire evaluation: the decision is not "should we add this package," it is "should we adopt Photon CMS, and if so, how do we own its bootstrap contract." The installer is inseparable from the CMS it installs — its config layout, migration set, admin/auth bootstrap, and module conventions. There is no standalone value. Architecturally it belongs in a one-time provisioning step (ephemeral container, CI job, or developer workstation), never in the production require block, and never reachable post-deploy.

Integration feasibility

Feasible only inside the framework generation Photon CMS was written for — Laravel 5.x-era (PHP 7.0–7.2). On a modern Laravel 9/10/11 and PHP 8.1+ baseline, expect Composer dependency resolution to fail first, then a cascade of removed-framework-API failures even if constraints are hand-relaxed. The realistic estimate is a fork-and-repair project, not an install, and that estimate should be socialized before anyone opens a ticket for "just try it." A containerized, time-boxed spike against the target baseline is the cheapest way to convert this risk into evidence.

Technical risk

High, and concentrated:

• Abandonment risk. Zero stars, zero dependents, score 0. No consumer base to inherit fixes or patches from, no visible test/CI signal, no issue triage.
• Installer-as-attack-surface. Installers of this class register web routes and/or Artisan commands that write .env, seed the first admin user, and run migrations. An unauthenticated installer endpoint left reachable post-install is a privilege-escalation path. Verification of route registration and self-disable logic is a mandatory gate, not a nice-to-have.
• Destructive, non-idempotent file and DB operations. Overwriting .env, config, and storage scaffolding makes re-runs silently clobber environment-specific settings; a failed migration/seed leaves a half-built schema with no rollback.
• Bus factor of one and no disclosure channel. No CVE feed, no security policy, no patch cadence. The adopting team owns vulnerability response end to end.
• Framework-generation drift. Every Laravel/PHP bump becomes an internally funded patch.

Key questions

1. What are the exact php and illuminate/* constraints, and do they resolve under our target baseline?
2. Does it register HTTP routes? If so, are they guarded, and how are they disabled post-install?
3. Is the flow idempotent, or does it mutate .env/config on re-run?
4. Is it a thin Artisan wrapper (low risk, easy to replace) or does it embed meaningful logic (migrations, seeders, module scaffolding)?
5. Who maintains Photon CMS upstream — last commit, license, paid support, security contact?
6. What is our exit cost if Photon stalls — how coupled would our domain logic become to its module system?

Integration Approach

Stack fit

Poor for a modern Laravel baseline; acceptable only for an existing Laravel 5.x-era Photon deployment. For greenfield work the correct disposition is reference-only: read the installer to learn Photon's expected directory layout and bootstrap sequence, then do not add it as a dependency. The TPM's job here is to make "reference-only" an explicit, recorded decision so it isn't quietly reversed by an engineer who finds the package first.

Migration path

• Already on Photon: move to require-dev, pin an exact version with a committed composer.lock, run only in an ephemeral container during provisioning, and capture the post-install state as a versioned artifact so the installer is never re-executed against a live environment.
• Evaluating Photon: time-box a spike in a throwaway container. Success criteria are a working admin login and a rendered content page — not "composer install succeeded." Kill the spike if framework constraints don't resolve cleanly.
• Not on Photon: no migration path. Recommend Laravel's first-party installer or a hand-rolled make:bootstrap target.

Compatibility

Three gates, in order: (1) Composer 2 resolution under our PHP ceiling; (2) Laravel framework API surface; (3) package auto-discovery / service-provider registration. Gate 3 is the usual silent failure — the package installs but its provider never boots, producing a half-configured app. Also confirm assumed database driver (MySQL vs SQLite) and filesystem permissions on storage/ and bootstrap/cache/, which bite in non-root containerized environments.

Sequencing

1. Vendor-risk review — last commit, license, maintainer, issue responsiveness.
2. Static source read: routes, commands, file writes, .env handling.
3. Containerized spike against the target baseline; record exact failure points.
4. Security review of any installer route; confirm post-install disablement.
5. Go/no-go at the CMS level, not the installer level.
6. If go: require-dev, pinned, CI-only execution, runbook written, installer excluded from the deploy artifact.

Operational Impact

Maintenance

Effectively unmaintained upstream. If adopted, budget internal ownership as a recurring line item: fork to a private VCS, track upstream manually, carry the patch burden for every PHP/Laravel bump. Scoping this as "setup work" is the most common planning error; it is ongoing maintenance with no vendor.

Support

No upstream contract, no disclosure process, no triage SLA. Escalation is "we fix it." Tolerable for a one-shot CI bootstrap that never runs in production; not tolerable if it turns out to be required at runtime or during post-deploy provisioning. Confirm which one it is before approval.

Scaling

Scaling impact is negligible and indirect — a one-shot operation measured in provisioning minutes, not request throughput. The scaling question belongs to Photon CMS itself (query patterns, caching, module overhead). Do not let installer evaluation substitute for CMS performance evaluation; separate workstreams, only the latter carries production risk.

Failure modes

• Partial install — migration or seeder failure leaves a half-built schema with no rollback; recovery is a database rebuild.
• Config clobbering — re-run overwrites .env/config with defaults, silently breaking environment-specific settings.
• Silent no-op — provider never registers, install "succeeds," app fails later at first admin login.
• Permission failures on storage//bootstrap/cache in containerized or non-root environments.
• Exposed installer endpoint — highest severity, and the one most likely to be missed because it surfaces as a security finding, not an error.
• Environment drift — devs run the installer locally while CI/staging are provisioned differently, producing irreproducible states.

Ramp-up

Low technical learning curve — one command — but high organizational learning cost, because the knowledge is undocumented and held by whoever ran the spike. Mitigate with a written runbook (exact command sequence, required env vars, expected output, rollback procedure) and a committed post-install artifact so the tool never needs re-running. Plan a multi-day spike for any team unfamiliar with Photon CMS before any commitment.

Recommendation to the review board: do not adopt photoncms/installer as a dependency. Zero dependents, zero community signal, and an incompatible framework generation mean the expected cost of fork-and-maintain exceeds the value of the scaffolding. Treat it as documentation of Photon CMS's bootstrap contract; gate any further investment on a separate, explicit decision to adopt Photon CMS. If onboarding friction for our own Laravel product is a real problem, open a small ticket to build our own installer using this package's sequence as a pattern — with a framework version we control and a maintainer we can page.