Translatable For Laravel Laravel Package

Technical Evaluation

Architecture fit: This package fits Laravel/PHP applications that model localized content through a $table->translatable(string $name) migration macro and want Larastan/PHPStan to understand that macro during static analysis. Release 1.1.2 is a developer-tooling compatibility patch: it fixes a static-analysis false positive when the service provider is not booted during PHPStan execution, such as package development under Testbench, dont-discover, or manually registered providers. It does not indicate a runtime architecture change.

Integration feasibility: Low-effort for teams already running Larastan/PHPStan. The package ships a PHPStan extension that phpstan/extension-installer loads automatically via extra.phpstan.includes. Without the installer, teams must explicitly include vendor/roundly-consulting/translatable-for-laravel/extension.neon. Teams not using static analysis see little impact from this release.

Technical risk: Runtime risk appears low based on the release notes. The main risk is static-analysis configuration: missing phpstan/extension-installer, custom provider discovery, or version mismatch between Laravel, Larastan/PHPStan, and the package. The package’s full compatibility matrix and schema-macro behavior are not established by the release notes alone.

Key questions: Which Laravel and PHP versions are supported? Does translatable() store data as JSON, separate columns, or related tables? What are the data-migration implications? Which Larastan/PHPStan versions are compatible? Does the host app use dont-discover or manual provider registration? Is the package actively maintained beyond this patch? Who owns PHPStan configuration in CI?

Integration Approach

Stack fit: Best fit is a Laravel app using migrations for localized content and Larastan/PHPStan in CI. It is less relevant where static analysis is absent or where translations are handled outside Eloquent/schema tooling.

Migration path: Treat 1.1.2 as a patch upgrade. No breaking changes or deprecations are indicated. Confirm phpstan/extension-installer is installed, or add vendor/roundly-consulting/translatable-for-laravel/extension.neon to the PHPStan configuration. Clear config caches and run PHPStan/Larastan plus migration tests. If the codebase currently suppresses “undefined method” errors for translatable(), remove those suppressions only after the extension is verified.

Compatibility: Validate against the project’s Laravel, PHP, Larastan, and PHPStan versions. Pay particular attention to apps using dont-discover, manually registered providers, or Testbench-based package development, because those are the contexts this release specifically addresses.

Sequencing: 1) Inventory PHPStan/Larastan usage and provider discovery settings. 2) Add the extension include or confirm extension-installer auto-loading. 3) Bump the package in a branch. 4) Run CI static analysis and migration tests. 5) Roll out to development/CI first; production runtime changes are likely minimal, but the migration macro should still be validated in staging.

Operational Impact

Maintenance: Low ongoing maintenance if the project uses standard Laravel auto-discovery and phpstan/extension-installer. Manual extension inclusion adds one configuration touchpoint to maintain. Keep PHPStan/Larastan and the package reasonably aligned.

Support: Support burden is mainly developer-tooling related: CI static-analysis failures, extension loading, and provider boot behavior. Runtime support is tied more to the translatable data model and schema macro than to this specific patch.

Scaling: No direct scaling impact is indicated. Translatable storage performance depends on the package’s underlying schema design—JSON columns, separate tables, or otherwise—not on this release. Static analysis may add minor CI time depending on the existing baseline.

Failure modes: The primary failure mode is the original static-analysis error: “Call to an undefined method” when the provider is not booted and the extension is not loaded. Other risks include missing phpstan/extension-installer without a manual include, PHPStan/Larastan version mismatch, and misunderstood migration-macro behavior. Runtime failure is possible if the macro/provider is not registered as expected.

Ramp-up: Low for Laravel teams already familiar with PHPStan/Larastan; moderate where static analysis is new or provider discovery is customized. A TPM should position 1.1.2 as a CI/developer-experience compatibility patch, gate adoption on a short static-analysis validation, and avoid treating it as a business-facing feature release.