Asgardcms Installer Laravel Package

Technical Evaluation

Architecture fit. This package is not a runtime dependency — it is a disposable scaffolding tool. It installs globally and exposes a console command that shells out to composer create-project asgardcms/platform <name>, then hands off to the platform's own interactive installer. Once the project exists, the installer has no presence in the codebase. That is the most favorable thing that can be said about its architecture: it cannot rot inside your application, only on developer machines and CI images.

The architectural constraint is inherited, not introduced: everything the installer produces is pinned to the AsgardCMS platform, which targets the Laravel 5.4–5.7 / PHP 7.1–7.4 era. It is greenfield-only tooling for a legacy stack. It does not augment an existing Laravel application and cannot be dropped into one.

Integration feasibility. Mechanically trivial (composer global require asgardcms/asgardcms-installer, then run the command). Strategically near-zero for any organization on a supported Laravel version. The realistic use is a bounded evaluation of AsgardCMS's modular-package and theming model, not adoption of the installer itself. Anything else implies downgrading Laravel by several majors, which is a non-starter.

Technical risk. High, and concentrated in upstream rather than in this repository:

• 28 stars and a composite score of ~1.23 are consistent with an effectively dormant ecosystem. Assume no upstream patches, no CVE response, no Composer 2 / PHP 8 fixes.
• composer create-project against an unmaintained namespace is a supply-chain surface: abandoned transitive packages, mutable Packagist metadata, and post-install scripts executing arbitrary platform code.
• Global Composer installs are an operational smell — bin-dir conflicts, version drift across developer machines, and non-reproducible onboarding.
• Interactive installer prompts fail or hang in non-TTY CI environments, producing silent partial installs.

Key questions.

1. Is the target greenfield or an existing application? If existing, this package is out of scope by definition.
2. Which AsgardCMS/PHP/Laravel version pairing is acceptable to the business, and who signs off on running an EOL framework in production?
3. If the value is the module system, why adopt the CMS wrapper rather than nwidart/laravel-modules on a supported Laravel version?
4. Who owns the fork when a dependency breaks? Is there an internal PHP maintainer with budget?
5. What is the actual business capability being bought — CMS authoring UX, multi-site theming, or modularity — and can it be sourced modern?

Integration Approach

Stack fit. Compatible only with a Laravel 5.x / PHP 7.x baseline. It does not compose with Laravel 9–11, PHP 8.1+, or modern Composer workflows. Treat it as a legacy-stack artifact.

Migration path. Do not position the installer as a migration vehicle. There are three coherent options, in descending order of preference:

1. Reference architecture only. Use a disposable container to generate one AsgardCMS instance, study the module registration and theming contracts, then build the equivalent on a current Laravel release. Cost: days.
2. Concept extraction. Map AsgardCMS's module structure onto nwidart/laravel-modules plus a maintained admin panel (Filament, Nova). Preserves the idea, discards the liability. Cost: weeks.
3. Fork and modernize. Fork asgardcms/platform and walk Laravel 5.7 → 11 across six majors. This is a rewrite wearing a migration costume. Cost: months, with no upstream to merge from.

Compatibility. Verify PHP constraint resolution, Composer major version behavior for create-project, global bin-dir configuration on CI runners, and Windows/WSL path handling. The command writes into the current working directory — confirm it does not collide with existing project roots in shared build agents.

Sequencing.

1. Timeboxed spike in a throwaway container; produce a written capability inventory.
2. Pin exact versions in a lockfile and record them before any second run.
3. Decision gate: fork vs. replace vs. discard — with the EOL-framework sign-off attached.
4. Only then provision durable tooling, and only if the fork path is chosen.

Operational Impact

Maintenance. Adoption means owning the platform. There is no upstream velocity to ride, so every framework CVE, PHP deprecation, and dependency abandonment becomes internal work. The installer itself is ~200 lines and low-maintenance; what it installs is the burden. Budget a standing allocation, not a one-time cost.

Support. No vendor, no SLA, and a community channel that is unlikely to be responsive. Supportability hinges on retaining an internal PHP/Laravel specialist who understands the module boot sequence and theming layer. That is a single-point-of-failure staffing risk, and it should be named as such in any approval.

Scaling. The installer is dev-time, so scaling concerns belong to the generated application. AsgardCMS boots every enabled module's service providers per request — acceptable at moderate traffic, noticeable under load. The application tier is stateless and scales horizontally without ceremony; the friction is in deployment, where per-module migrations and asset/theme compilation make releases heavier and less atomic than a standard Laravel deploy.

Failure modes.

• Dependency resolution failure from abandoned transitive packages during create-project.
• PHP version mismatch on the runner, surfacing as an opaque Composer error.
• Post-install script failure leaving a half-scaffolded directory that looks usable.
• Interactive prompt hangs in non-TTY CI, silently stalling pipelines.
• Global Composer bin-dir conflicts across developer machines, producing "works on my machine" onboarding.
• Divergence between spike environments and production once the installer is no longer re-run.

Ramp-up. Running the tool: under an hour, any Laravel developer. Understanding and safely owning the resulting platform: several weeks minimum, and materially longer if the fork-and-upgrade path is selected. Plan onboarding around the platform, not the installer — the installer is the easy part and the least of the decision.