Laravel Language Laravel Package

Technical Evaluation

Architecture fit. This is a conventional Laravel package: service provider + facade, a Language service class, Eloquent model/migration/factory, middleware (SetLanguageMiddleware, SetTimezoneMiddleware), a custom cast (DateBasedOnCalendarCast), validation rules (LanguageExistRule, CheckLocaleRule, CheckFutureDateRule), and domain events (LanguageStoredEvent, SetLocaleEvent). That is idiomatic Laravel and will feel familiar to any team already shipping Laravel packages. The complication is that the package is mid-decomposition: this release removes DateConverter and pushes it into panelify/multi-calendar (1.2), moves validation-error handling into panelify/core (1.26), and strips code that is relocating to panelify/language. The effective surface area we would consume is shifting between sibling packages, which means our integration boundary is not stable yet.

Integration feasibility. Mechanically straightforward — composer install, publish config/migrations, register middleware, register listeners. Two hard gates: the package now requires PHP 8.2, and the Laravel query builder dependency moved 5.7 → 6.3, a major-version jump that likely constrains the supported Laravel range. We also inherit a transitive graph of panelify/core and panelify/multi-calendar, plus a runtime dependency on the PHP intl extension implied by the date-conversion work. Feasibility is high for a greenfield service on PHP 8.2/Laravel 11; it is a scheduled project rather than an afternoon for an existing app.

Technical risk. The dominant risk is release hygiene, not code quality. A patch release (2.1.1) carries renames of public symbols (LangaugeAddEvent → LanguageStoredEvent, addLanguageDate → addLanguageData), namespace changes (SetLocaleEvent, exception classes), removal of DateConverter, a changed facade resolution path, a new required PHP version, and a major dependency bump. Each of those is a breaking change shipped under a patch version. The changelog also contains duplicated entries and typos, which suggests it is hand-assembled from commit messages rather than curated — so absence of a line item is not evidence a change didn't happen. Test coverage, however, is a genuine positive: new tests accompany the middleware, cast, rules, and service work, which materially lowers the risk of silent behavioral regressions.

Key questions.

1. Are panelify/core and panelify/multi-calendar publicly released, documented, and supported, or are they effectively internal packages we would be adopting without an upgrade contract?
2. What is the official Laravel version support matrix after the query builder 6.3 bump?
3. Was the 2.1.1 version number intentional, or is this a cumulative changelog for a minor/major that was mis-tagged?
4. Does the calendar column added to the language migration require a data backfill on existing installs?
5. Is DateConverter fully removed, or deprecated-but-present? Are old event/method names aliased for one release?
6. Does the intl extension requirement apply to consumers of the cast, the middleware, or only the removed converter?

Integration Approach

Stack fit. Best fit is a Laravel application on PHP 8.2+ with a recent framework version (the query builder 6.3 pin points at Laravel 10/11-era). The package assumes a relational database with a language table it migrates, per-request locale and timezone resolution via middleware, and calendar-aware date presentation via Eloquent casts. Applications already managing locale at the framework level (app()->setLocale) will need to reconcile two sources of truth — this package's Language table becomes authoritative, and SetLanguageMiddleware should be the only writer of the request locale.

Migration path.

1. Pin 2.1.1 exactly in a branch; do not adopt with ^2.1.
2. Grep the codebase for removed/renamed symbols: DateConverter, LangaugeAddEvent, addLanguageDate, and any imports from changed namespaces (SetLocaleEvent, exception classes).
3. Inventory all listeners on language events and all façade call sites; the façade is now resolved via service-provider registration, so any container-tag or manual binding assumptions need re-checking.
4. Replace DateConverter usage with the panelify/multi-calendar equivalent before upgrading, not after.
5. Run migrations against a scrubbed copy of production first — the new calendar field and changed phpdoc on the migration need a backfill check.

Compatibility. Treat this as a coordinated multi-package upgrade: panelify/core 1.20 → 1.26, multi-calendar → 1.2, query builder 5.7 → 6.3, PHP floor → 8.2. Any one of these failing blocks the whole train. Build a compatibility matrix against our actual PHP and Laravel versions in week one, before committing to a delivery date.

Sequencing.

1. Compatibility spike: PHP/Laravel/extensions check, dependency resolution dry-run in a throwaway app.
2. Symbol audit and DateConverter replacement plan (largest unknown).
3. Sandbox install + boot test: façade resolves, middleware registers, migrations run clean on seeded data.
4. Port existing locale handling onto SetLanguageMiddleware; consolidate to a single source of truth.
5. Update event listeners to renamed events and namespace changes.
6. Full regression on date/calendar display, locale switching, and timezone-shifted timestamps — these are the blast radii of the cast and middleware changes.
7. Staging soak, then production behind a feature flag on the locale middleware if possible.

Operational Impact

Maintenance. Adoption means tracking three or more packages in lockstep (language, core, multi-calendar), each moving independently — core went 1.20 → 1.26 within this same window. Because the changelog is unreliable, pin exact versions and diff composer.lock and the public API surface on every upgrade rather than trusting release notes. Budget a recurring line item for upgrade triage; this is not a set-and-forget dependency.

Support. The support model is the biggest open question. If these are first-party/internal packages, name an owning team and require documented breaking-change notices before future bumps. If they are third-party but low-visibility, assume best-effort community support and plan to fork or vendor if the package becomes load-bearing. The presence of tests, a base TestCase, and new documentation is reassuring for code stability but says nothing about response times.

Scaling. Runtime cost is low: middleware and a cast per request, plus one lookup against the language table. That lookup is the only scaling concern — it will run on every localized request. Cache the language/locale/calendar resolution in the application cache layer rather than querying per request, and validate cache invalidation on LanguageStoredEvent. Calendar conversion via intl is CPU-cheap and does not need special sizing.

Failure modes to instrument.

• Boot-time binding failure — the changed façade/service-provider registration can fail silently or loudly depending on how call sites resolve it. Add a boot smoke test.
• Missing calendar column — the migration changed; a partial rollout yields SQL errors on any query touching the cast. Gate deploy on migration completion.
• Timezone middleware misconfiguration — SetTimezoneMiddleware and the new helper shift timestamp interpretation; misordering middleware relative to locale resolution can silently produce off-by-one-day dates.
• Absent intl extension — fails only on the code paths that reach date conversion, which is easy to miss in CI if tests mock the converter.
• Validation rules failing open or closed — confirm whether LanguageExistRule and CheckLocaleRule reject unknown locales or pass them through; this determines user-visible behavior on malformed input.
• Stale locale cache — languages updated via LanguageStoredEvent but not evicted.

Ramp-up. Low-to-medium for a Laravel-fluent engineer: the package uses standard conventions, and the new helper method for SetTimezoneMiddleware reduces configuration boilerplate. The ramp-up cost is not learning the API — it is reverse-engineering the actual behavior, because the changelog won't tell you what changed. Plan a half-day of source reading and a day of test-writing against the middleware and cast before the first production deploy.