Plugins Laravel Package

Technical Evaluation

Architecture fit

• laravilt/plugins is a Laravel package (service-provider based, built on spatie/laravel-package-tools) that provides plugin/module registration, discovery, dependency resolution, and stub-driven scaffolding. It fits a modular-monolith architecture where a host Laravel app composes first-party and third-party plugins.
• v1.1.0 signals the package is maturing along two axes: framework breadth (Laravel 13 support) and frontend breadth (React added alongside the existing Vue-oriented flow). That expands the addressable team profile but also widens the surface the package must own.
• The frontend coupling is the architectural question mark. A backend package that generates/owns frontend scaffolding and assets is convenient, but it makes the package a partial owner of the app's asset pipeline — a commitment that is harder to reverse than a composer-side plugin registry.

Integration feasibility

• Low-friction on the PHP side: composer install, service provider auto-discovery, standard Artisan-driven plugin lifecycle. No infrastructure prerequisites beyond the framework version.
• The React addition is the first decision point. If the host app is Vue/Inertia today, v1.1.0 is effectively a no-op feature-wise; if greenfield, React becomes a viable option — but it must be validated against the app's existing build tooling, not just the package's generated stubs.
• "Fix plugin dependency handling and generated stubs" is the highest-value item in this release and also the most under-documented. Behavioral changes in dependency resolution typically do not surface until a plugin is installed/upgraded in a non-trivial graph.

Technical risk

• Generated-stub drift (medium). Stub changes mean plugins scaffolded pre-1.1.0 and plugins scaffolded post-1.1.0 may not be structurally identical. Any process that re-scaffolds or diffs stubs during upgrade will produce noise.
• Dependency-resolution semantics (medium). A "fix" to dependency handling can convert previously-tolerated cycles, missing constraints, or ordering assumptions into hard failures at activation time.
• Distribution regression from removing the npm publish workflow (medium–high, needs confirmation). If any JS/asset artifact was previously published to a registry, 1.1.0 consumers may silently pin to a stale artifact or find it unpublished. This is the single change in the release most likely to cause an outage-shaped surprise.
• Semver hygiene (low). Laravel 13 compatibility and React support were shipped in a minor bump. Acceptable under semver, but a TPM should not treat "minor" as "no regression testing needed" here.
• Dependabot noise (low). The bulk of the changelog is tooling churn (Pint, Larastan, PHPStan plugins, Testbench, spatie/laravel-package-tools, GitHub Actions majors). Low product risk, but it does mean this release's real content is a small fraction of its diff — reviewers who skim the changelog will mis-size it.

Key questions

1. Was anything published to npm at v1.0.2, and what is the published-asset path now that the npm publish workflow is gone?
2. Do existing plugins need re-scaffolding or regeneration after the stub fixes, and is there a documented upgrade note?
3. What changed in dependency-resolution semantics — cycle detection, version constraints, activation order — and is it backward compatible for existing plugin graphs?
4. Is React support additive (both stacks supported, chosen at scaffold time) or does it introduce a project-level mode that locks the app in?
5. Does "Laravel 13 compatibility" come with a dropped floor (e.g. Laravel 11 support removed)? The notes do not say.
6. Do the GitHub Actions bumps propagate into generated plugin CI templates? If so, downstream plugins inherit major-version CI changes.

Integration Approach

Stack fit

• PHP/Laravel host with a modular monolith or a plugin-extensible product line. Composer-native; no new runtime services.
• Frontend: confirm the target stack before adopting. Vue/Inertia teams get a stability-and-compat upgrade only; React teams get a newly viable path — but one with no production track record in this package.

Migration path

• Patch-level upgrade (1.0.2 → 1.1.0) from composer's perspective; treat it as a minor-scope change in practice.
• Recommended path: upgrade in a branch, run the full existing plugin suite, then diff generated output for one representative plugin to see exactly what the stub fixes changed. Do not upgrade plugin scaffolding and framework version in the same change set.
• If the app consumes any JS artifact from this package, resolve question 1 before merging.

Compatibility

• Verify the Laravel version floor and ceiling explicitly — 1.1.0 adds Laravel 13, but the notes are silent on whether older majors remain supported.
• Verify Testbench/PHPStan/Pint bumps do not raise the package's own PHP floor beyond the host app's runtime.
• Check that existing plugin manifests still resolve; dependency-handling fixes are the likeliest source of activation-time breakage.

Sequencing

1. Confirm asset-distribution story and Laravel version matrix (unblocks everything else).
2. Upgrade a non-production environment; run plugin activation/deactivation tests against the real plugin graph, not just the package's test suite.
3. Regenerate one plugin's stubs and review the diff; decide whether a bulk regeneration is required or optional.
4. Adopt React support only after (2)–(3) are clean, and only on a new or explicitly-migrated surface.
5. Roll to production; keep the previous composer lock revertible for one release cycle.

Operational Impact

Maintenance

• Ongoing cost is low for the host app: composer updates plus a periodic plugin-regeneration review.
• The stub and dependency-resolution churn in a single minor release is a signal that these areas are still settling. Budget for one to two more breaking-ish minor releases before treating the scaffold contract as stable.
• Dependabot-driven releases will keep arriving frequently; the team needs a triage rule that separates tooling churn from product-affecting changes rather than reviewing each release as equivalent.

Support

• Support burden concentrates on two questions: "why doesn't my plugin activate" (dependency resolution) and "why does my generated code look different" (stubs). Both need internal documentation, not just upstream links.
• If a frontend stack is now genuinely dual (Vue + React), first-line support must know which stack each internal plugin targets; ambiguity here produces misrouted issues.

Scaling

• Plugin dependency resolution scales with graph size and is the natural bottleneck for large internal plugin catalogs. Test with a realistic graph (10+ plugins, at least one shared dependency) rather than a two-plugin fixture.
• React support scales team onboarding but fragments frontend conventions across plugins. Pick one stack as the default and treat the other as opt-in to avoid a mixed estate.

Failure modes

• Silent stale JS artifact if the npm workflow removal orphaned a published package — fails at build/deploy, not at composer install.
• Plugin activation failure or ordering error after the dependency-handling fix — fails at boot, high blast radius.
• Stub drift causing divergent plugin structures — fails slowly, shows up as inconsistent code review and onboarding friction.
• Framework floor mismatch (Laravel 13 addition masking a dropped older major) — fails at composer resolution, loud and cheap to fix.

Ramp-up

• Backend engineers: roughly half a day to productivity with the plugin lifecycle and Artisan commands.
• Frontend engineers: React path is new and undocumented in the release notes; assume one to two days of spike work to establish a working scaffold before committing a team to it.
• TPM-level: this release does not require a program-level decision, but it does require a short technical spike and a written answer to the asset-distribution question before it is treated as a routine patch bump.