Core Laravel Package

Technical Evaluation

Architecture fit

artisanpack-ui/core is a foundation layer, not a feature package. Its stated job is to unify configuration from every sibling ArtisanPack UI package into a single config/artisanpack.php, and since 1.2.0 it also ships shared plumbing: an abstract ArtisanPackServiceProvider, a ConfigurationManager, logging/audit infrastructure, a Blade directive registrar, a base facade, an exception hierarchy, enums/constants, and a testing base case. That makes it an ecosystem contract — the value proposition is only realized if we adopt at least a few ArtisanPack UI packages (CMS framework, visual editor, UI components, accessibility). In a standalone Laravel app it is a small convenience layer plus a set of artisan commands.

Architecturally the package is idiomatic Laravel: package discovery, a registerable service provider, a publish tag (artisanpack-config), singletons resolved through the container, and facades. Nothing exotic, no PHP extensions beyond the standard set, no queue or event-loop coupling. It will sit cleanly alongside an existing app's config and service providers. The one design choice to scrutinize is that configuration centralization is implemented as a file-mutating artisan command rather than a runtime merge — this is simpler to reason about but means config state lives in version-controlled PHP that a command rewrites.

Integration feasibility

Low technical effort: composer require artisanpack-ui/core, auto-registration, one publish command, one scaffold command. The prerequisites are PHP ^8.2 and Laravel 11–13, all of which a current Laravel codebase should satisfy. The real feasibility question is not "can we install it" but "do we intend to adopt the ecosystem it fronts." For a TPM, this is a scoping decision: if the answer is no, the package's remaining value is limited to the operational commands (artisanpack:diagnose, artisanpack:check-compatibility, artisanpack:check-updates, artisanpack:make-package) and the testing base classes — useful, but not a compelling reason on their own.

Technical risk

Key questions

1. What is the adoption roadmap for the ArtisanPack UI ecosystem, and is core intended as a hard dependency for all sibling packages?
2. Who maintains this beyond the current author, and is there a documented security disclosure and release cadence?
3. Why were breaking changes in 1.1.0 released as a minor version — is SemVer compliance part of the project's contract?
4. Does artisanpack:check-updates transmit anything beyond package names, and is it safe to run in air-gapped or restricted CI?
5. Is the "one central config file" model the long-term direction, or a transitional approach before per-package config publishing?
6. Can ConfigurationManager be used without adopting the full provider base class, and is that a supported configuration?
7. What is the compatibility guarantee across Laravel 11/12/13 and PHP 8.2/8.3 — is the full matrix CI-tested (the changelog suggests yes, but we should verify)?

Integration Approach

Stack fit

Good fit for Laravel 11/12/13 applications on PHP 8.2+, particularly ones already standardized on Laravel's config/ conventions and comfortable with artisan-driven developer tooling. It is a poor fit for non-Laravel PHP services, for polyglot monorepos where a PHP-specific config convention adds a second source of truth, or for teams with strict third-party dependency review processes — an unproven 1-star foundation package will likely fail that gate without an exception.

Migration path

There is nothing to migrate from unless we already use ArtisanPack UI packages. Two entry scenarios:

• Greenfield / ecosystem adoption: install core first, publish the base config, then add sibling packages and re-run artisanpack:scaffold-config. This is the intended path and is clean.
• Retrofit into an existing app: the package adds a new config/artisanpack.php; it does not touch existing config. Actual migration cost appears only if we later move package settings out of per-package config files into the unified file. Treat that consolidation as a separate, optional initiative — do not bundle it into the initial install.

Compatibility

• PHP 8.2 pins us to Laravel 11/12; Laravel 13 requires PHP 8.3+. Confirm our runtime matrix before committing to a version range.
• ^1.0 is not a safe constraint given the 1.1.0 breaking change. Pin to an explicit minor (^1.2) and review the changelog on every bump.
• Verify no collision with an existing config/artisanpack.php or an existing artisanpack service-container alias.

Sequencing

1. Time-boxed spike (0.5–1 day): fresh Laravel 12 app, install core, publish config, run artisanpack:scaffold-config and artisanpack:diagnose. Confirm commands behave and inspect what the scaffold writes.
2. Compatibility probe: run artisanpack:check-compatibility and artisanpack:diagnose --json against a representative real application in a branch. Diff the config file before/after.
3. Decision gate: adopt only if a concrete sibling package (e.g. accessibility or CMS framework) is on the roadmap. If not, document core as "not adopted" and, if the diagnostic/testing utilities alone are wanted, vendor the specific ideas rather than the dependency.
4. Pilot: one internal, low-blast-radius application. Wrap the scaffold command in a documented runbook step with a git-clean precondition.
5. Widen: only after 4–6 weeks of incident-free operation and confirmation that the ecosystem is actively maintained.

Operational Impact

Maintenance

Runtime maintenance is negligible — this is config helpers and a service provider, with no background processes, migrations, or storage. The ongoing cost is upgrade cost: the project is moving fast and has already shipped breaking changes in a minor release. Budget for a changelog review on every composer update, and pin versions in composer.json with a lockfile committed. The config file becomes a maintained artifact owned by whoever runs the scaffold command; treat it like code, not generated output.

Support

MIT-licensed, community-supported, no vendor SLA. Internal support burden falls on the adopting team. Mitigations: read the source (it is small), keep the exception hierarchy in mind (ArtisanPackException and subclasses give a single catch point), and don't route critical paths through the facade without a fallback. Escalation path is GitHub issues only — factor that into risk acceptance for anything customer-facing.

Scaling

Effectively zero runtime cost: config merging happens at install/scaffold time and access is Laravel's native config() lookup. The scaling concern is organizational, not technical — as more sibling packages are added, the single artisanpack.php grows and becomes a merge-conflict hotspot across teams. Consider ownership rules (who may edit which section) before the file exceeds a few hundred lines.

Failure modes

• Silent config drift: scaffold detects only packages that correctly tag their config; a mistagged package is skipped without loud failure. Always diff the file after scaffolding.
• Overwritten customizations: --force is destructive. Never run it in a pipeline; require a clean working tree.
• Missing-service exceptions: facades resolve container bindings that may not exist if a sibling package isn't installed. The base facade is designed to improve these messages, but wrap resolution in availability checks.
• Network dependency: check-updates depends on Packagist and a cache backend; expect failures in restricted networks or behind proxies, and don't put it on a critical CI path.
• Version skew: mixing package versions across the ecosystem is the most likely source of hard-to-diagnose issues; check-compatibility --strict is the right gate but only if the ecosystem is actually installed.
• Abandonment: given the adoption numbers, the realistic worst case is the project going quiet. Because the package is small, MIT, and mostly additive, the exit cost is a straightforward removal plus inlining any helpers we came to depend on — acceptable, provided we don't couple core app logic to its facades.

Ramp-up

Roughly half a day for an experienced Laravel engineer to install, publish, scaffold, and understand the config model; 1–2 days to become productive with the wider 1.2.0 services (ConfigurationManager, logging/audit, testing base case). The testing utilities (ArtisanPackTestCase plus assertions and mocking concerns) meaningfully reduce ramp-up for sibling-package work and are the most defensible part of the package for a team that is not fully committing to the ecosystem. Documentation is present — README, docs, changelog, upgrade guide — which is above average for a package at this adoption level, but the material is maintainer-authored and has no independent validation. Plan a short internal knowledge-transfer note so the team isn't dependent on one person's reading of the source.