Ide Helper Extension Laravel Package

Product Decisions This Supports

• Developer experience (DX) investment for legacy CMS estates. If your product runs on PyroCMS (a Laravel-based CMS), this extension exists to generate IDE metadata for PyroCMS addons/modules, so engineers get autocomplete and type hints on framework and addon surfaces they would otherwise reverse-engineer by hand. The decision it informs is narrow: whether to spend a small amount of engineering time improving editor tooling on an existing PyroCMS codebase.
• Onboarding time for new engineers on a PyroCMS codebase. IDE hints shorten the ramp for contributors unfamiliar with PyroCMS's module conventions. This is a measurable input to onboarding cost, not a feature.
• Build vs. buy vs. skip for internal tooling. The realistic comparison is not "adopt vs. not adopt" but "write our own addon-aware stub generator vs. fork this vs. rely on barryvdh/laravel-ide-helper plus Larastan." Given zero stars and zero dependents, the default PM stance is skip or fork, not adopt.
• Maintenance/risk budgeting for a platform decision already made. The package does not drive roadmap; it reflects a prior decision (staying on PyroCMS). It should be treated as a line item under "cost of maintaining a legacy platform," and it strengthens the case for a migration assessment rather than for new feature work.
• Not a customer-facing feature. There is no end-user value, no revenue path, and no roadmap item this should appear on. It belongs in engineering enablement, not the product backlog.

When to Consider This Package

Consider it only when all of the following hold:

• You are actively maintaining a PyroCMS 3.x (Laravel-based) application, not a greenfield Laravel project.
• Your team works inside PyroCMS addons/modules and is repeatedly losing time to missing type information in the editor.
• You have already evaluated barryvdh/laravel-ide-helper and Larastan/PHPStan and found a genuine gap specifically around PyroCMS addon-generated classes.
• You are willing to vendor or fork the code, pin it, and own it, because the upstream signals (no stars, no dependents, single-vendor origin under a gitlab.com/.../pyrocms/... path) indicate effectively no community support and no maintenance guarantee.
• The cost of trying it is measured in hours, not sprints, and it touches dev dependencies only — never production runtime.

Look elsewhere — and by default assume you should — when:

• You are on modern Laravel, Livewire, Filament, or any non-PyroCMS stack. Use barryvdh/laravel-ide-helper and Larastan; they are maintained, widely adopted, and cover the same need.
• You need static analysis as a CI gate rather than editor convenience. PHPStan/Psalm/Larastan with a baseline is the durable answer; generated PHPDoc stubs are a convenience layer, not a quality gate.
• You require a supported dependency with a security-response path, changelog, or versioning discipline. None of that is evidenced here.
• Your actual goal is escaping the platform. A migration to a maintained Laravel application dominates this package on every axis — hiring, security patching, ecosystem access, and long-term DX.

How to Pitch It (Stakeholders)

For executives: This is a tiny, developer-only helper for teams already running PyroCMS. It improves editor autocomplete for that CMS's addons. It has no customer impact, no revenue impact, and negligible cost — but also no community backing: zero stars, zero downstream dependents, single-source maintenance. Treat any use as a small internal convenience we own and can drop, not a strategic dependency. Its most useful signal is diagnostic: needing packages like this is evidence that our platform choice is costing us developer velocity, and that should feed the next platform-review conversation.

For engineering leadership: Approve a time-boxed spike (a few hours), not an adoption. Requirements: dev-dependency only, pinned or vendored, an owner named, and an exit criterion — if it breaks or is unmaintained, we delete it and fall back to barryvdh/laravel-ide-helper + Larastan. Do not let it into the production dependency graph or the CI critical path.

For engineers: Try it in a scratch branch. If it materially cuts time spent chasing PyroCMS addon types, fork it into our namespace so we control it; if the gain is marginal — which is likely — close the spike and invest the same hours in PHPStan baselines and better stubs we generate ourselves.