Subscriptions Filament Laravel Package

Technical Evaluation

v2.1.1 is a patch release with two integration-focused fixes: PlansTable no longer requires the host Plan model to implement formattedPrice(), and MoneyField/CurrencyField no longer depend on an unreleased crumbls/subscriptions currency service. This reduces coupling to host application internals and improves compatibility with released crumbls/subscriptions 2.x versions.

Architecture fit: Good for Laravel applications using crumbls/subscriptions 2.x that need package-provided plan listing and money/currency form fields. The package now behaves more like a self-contained Laravel UI/integration layer: it can format decimal plan prices itself while still honoring custom host models that expose formattedPrice(). That is a sensible extension point and lowers the barrier for standard host Plan models.

Integration feasibility: High for existing Laravel apps already on crumbls/subscriptions 2.x. The release removes two integration blockers: mandatory host-model method implementation and dependency on an unreleased currency service. Existing apps with custom formattedPrice() should remain compatible by design, though their output should be regression-tested.

Technical risk: Low-to-moderate. No breaking changes are indicated, but there is a behavioral change: plan prices will now be formatted by the package when the host model does not provide formattedPrice(). Risk is concentrated in price/currency display correctness across locales, currencies, precision, and rounding. Apps that previously worked around the missing currency service or relied on implicit dev dependencies should validate forms and table output after upgrade.

Key questions:

• Which Laravel, PHP, Livewire/Filament, and crumbls/subscriptions 2.x version ranges are officially supported?
• How does package-side decimal formatting handle locale, currency symbols, precision, rounding, and zero-decimal currencies?
• Is formattedPrice() still the preferred override point, and are there edge cases where package formatting and custom formatting diverge?
• Are MoneyField and CurrencyField public APIs stable, and do they require config or asset republication?
• Does removing the unreleased currency service change any configuration, service binding, or published view assumptions?
• What test coverage exists for plan create/edit forms against multiple crumbls/subscriptions 2.x patch releases?

Integration Approach

Stack fit: Strong fit for Laravel applications using crumbls/subscriptions 2.x and package-provided plan administration UI. The release is especially relevant where host Plan models are simple Eloquent models and where teams do not want to add presentation methods solely to satisfy the package.

Migration path: Treat v2.1.1 as a low-risk patch upgrade. Update via Composer in a staging branch, then verify:

1. plan index/table rendering;
2. plan create and edit forms using MoneyField and CurrencyField;
3. price display for plans with and without custom formattedPrice();
4. behavior with existing published config/assets, if any.

If the host app previously added formattedPrice() only as a workaround, it can remain in place initially and be removed later after confirming package formatting meets requirements. If the app pinned or worked around the unreleased currency service, remove that workaround only after staging validation.

Compatibility: The release explicitly targets crumbls/subscriptions 2.x compatibility and preserves custom formattedPrice() behavior. Main compatibility checks are the host app’s Laravel/PHP version, frontend stack assumptions for the table/form components, and any app-specific currency formatting conventions.

Sequencing:

1. Inventory current crumbls/subscriptions and package versions.
2. Upgrade package to v2.1.1 in staging.
3. Run plan list/create/edit smoke tests.
4. Add regression checks for multiple currencies, decimal precision, and custom formattedPrice() models.
5. Remove obsolete workarounds only after QA sign-off.
6. Deploy with standard rollback to the prior package version if formatting defects appear.

Operational Impact

Maintenance: Positive. Removing the hard dependency on an unreleased currency service reduces maintenance drag and avoids tracking a non-released dependency. Making formattedPrice() optional also reduces host-app boilerplate.

Support: Support burden should decrease for standard Laravel/crumbls/subscriptions 2.x installations. Support may still be needed where teams depend on custom currency formatting or previously worked around the unreleased service. Document the new default formatting behavior and the continued formattedPrice() override path.

Scaling: No material scaling impact expected; this is primarily a presentation/integration fix. Runtime impact should be negligible unless package-side formatting performs additional currency/locale work per row, which should be validated for large plan tables.

Failure modes: Main failure modes are price-formatting mismatches, currency symbol/precision errors, locale-specific display defects, form-field rendering regressions, and dependency resolution conflicts with older crumbls/subscriptions versions. Because the package now formats decimal prices itself, QA should explicitly compare package output against business expectations rather than assuming host-model formatting.

Ramp-up: Low for Laravel developers familiar with crumbls/subscriptions. TPM should schedule focused QA on money/currency behavior and plan CRUD flows, and should confirm supported version ranges before broad rollout. Recommendation: pilot v2.1.1 in staging and adopt for apps on crumbls/subscriptions 2.x after price-formatting regression checks.