Spellcheck Symfony Bundle Laravel Package

Technical Evaluation

Architecture fit — Poor as a direct fit, and this is the headline finding for a Laravel shop. Despite the "PHP package" framing, v1.0.0 is a Symfony bundle, not a Laravel package. It ships a Bundle class registered through config/bundles.php, relies on Symfony's DI extension points (six of them, autoconfigured), the Symfony console, and presumably kernel/event wiring. Laravel has no bundle-loading mechanism; a composer require would install the code but none of the seven commands or services would be reachable through Artisan or Laravel's container. The genuinely reusable asset is the underlying framework-agnostic engine, php-spellcheck/spellcheck-core ^1.0 — everything of value (locale-aware catalogue checking, placeholder/HTML/ICU stripping, baseline diffing, report formatters) lives there or is thin glue over it.

Integration feasibility — Two viable routes, neither turnkey. (a) Depend on spellcheck-core directly and write a Laravel-native wrapper: one service provider, one or two Artisan commands, a config file. This is the recommended route and is a modest, well-scoped piece of work because the hard parsing logic is already in core. (b) Install the bundle anyway and shell out to its commands via Symfony\Component\Console\Application invoked from an Artisan command — workable but fragile, and it drags Symfony bundle machinery into an app that will never register the bundle. The --dev constraint is a real positive: this never reaches production runtime, so blast radius is limited to developer machines and CI.

Technical risk — Moderate, concentrated in dependency resolution rather than runtime behaviour.

• Composer conflicts. The bundle constrains symfony/* to 5.4 LTS / 6.4 LTS / 7.x / 8.x. Laravel already pins symfony/console, symfony/process, symfony/http-foundation, symfony/finder and others at versions tied to the Laravel major. A Laravel 10 or 11 app on Symfony 6.3/6.4 components is plausible to resolve, but this must be proven by an actual composer require --dev in a representative app, not assumed. Route (a) sidesteps most of this.
• PHP floor. PHP 8.1 is compatible with Laravel 10+; check that the constraint's upper bound (8.5) doesn't collide with pinned platform.php configs in CI images.
• Backend availability. hunspell, aspell and ext-pspell all require system binaries or extensions that are typically absent from slim CI containers. Only the pure-PHP wordlist backend is dependency-free, so it is the only realistic default; dictionary coverage and quality for non-English locales via wordlist is unverified and is a quality risk for i18n-heavy projects.
• Design conservatism is a plus. Avoiding AbstractBundle, 6.1+ attributes and autowiring signals a maintainer optimising for broad compatibility — a good signal for a 1.0, though it also means the codebase carries legacy-shaped patterns.
• Maturity. A first stable release at v1.0.0 with a single maintainer-org provenance and no prior assessment on record means no internal track record. Treat as an evaluated-but-unproven dependency.

Key questions for the maintainer / for the spike

1. Is there any intent to ship a Laravel service provider or a framework-agnostic CLI, or is spellcheck-core the officially sanctioned integration surface for non-Symfony frameworks?
2. What is the wordlist backend's dictionary sourcing model (bundled, downloaded, system-provided), and what locale coverage does it realistically achieve versus hunspell?
3. Does spellcheck-core expose a stable public API, or is it effectively internal to the bundle? Semver guarantees here determine whether route (a) is safe.
4. Can the bundle's commands be invoked standalone against a directory of files with no Symfony kernel booted?

Integration Approach

Stack fit — Assume no first-party Laravel fit and budget accordingly. The package belongs in the require-dev dependency set behind a custom Artisan command, not in application code. Treat the Symfony bundle as a reference implementation and feature specification rather than a dependency: it documents exactly which behaviours (ICU plural/select expansion, placeholder and markdown-code stripping with column preservation, locale-to-dictionary mapping, baseline filtering) the core engine supports and that we would need to surface.

Migration path — None required; there is nothing to migrate from. This is a greenfield developer-tooling addition with no schema, no runtime code path and no data migration. The only "migration" is cultural: moving teams from ad-hoc spellchecking or no spellchecking to a gated CI step, which the baseline feature is explicitly designed to make incremental.

Compatibility — Validate against the actual support matrix rather than the upstream one. Concretely: the two or three Laravel majors in production, the PHP versions in CI, and whether the app already pins Symfony component versions. The bundle's own compatibility story (Symfony 5.4 floor, no autowiring assumptions) is well-engineered for Symfony but tells us nothing about Laravel; the relevant artefact is a lockfile diff from a throwaway branch in a real application.

Sequencing

1. Spike (days). In a representative app on a throwaway branch, attempt composer require --dev php-spellcheck/spellcheck-core and, separately, the bundle. Record resolution outcome, install footprint and any Symfony version drift. Success criterion: core installs clean; bundle resolves or is cleanly ruled out.
2. Core proof of concept. Script the core engine against one real lang/ directory with the wordlist backend. Measure false-positive volume on existing translations and on PHP source — this number, not the feature list, decides whether the tool is adoptable.
3. Laravel wrapper. Service provider plus spellcheck:run and spellcheck:doctor equivalents, a config file for locale mapping and backend selection, and baseline file generation. Keep it thin; do not reimplement parsing.
4. CI wiring. Emit GitHub Actions annotations or GitLab Code Quality JSON — both formats are already produced by the core, so this is configuration, not code. Gate on new typos only via baseline.
5. Pilot on one repository, then widen. Revisit the bundle dependency if upstream ships a framework-agnostic entry point.

Operational Impact

Maintenance — Low ongoing cost if route (a) is taken: the wrapper is a few hundred lines against a stable core, and dictionary/parsing improvements arrive by version bump. Route (b) is higher maintenance because we would own an unsupported invocation path and absorb Symfony-constraint churn from a package that has no reason to consider Laravel's dependency graph. Either way, pin the core version and review upstream releases; a 1.0 with no prior internal history warrants reading changelogs before minor bumps.

Support — No vendor support relationship; upstream issues are community-driven. Internal support burden falls on whichever platform team owns the wrapper. Documentation for developers is essential: what the baseline means, how to regenerate it, why a flagged "typo" is usually a legitimate identifier or a domain term, and the allowlist/ignore mechanism (confirm whether core supports custom dictionaries — this is the difference between an adopted tool and a disabled one).

Scaling — Comfortable. It is a batch developer tool, not a request-path service; cost is CI minutes proportional to source and catalogue size. The pure-PHP wordlist backend will be measurably slower than hunspell on large codebases, so runtime should be observed in the spike and the command scoped (e.g. changed files on PRs, full run nightly) if it becomes a bottleneck. No concurrency, storage or quota concerns.

Failure modes

• False-positive flood on domain vocabulary, framework identifiers and non-English catalogues → developers disable the gate. Mitigate with baseline-first rollout, custom dictionaries, and an explicit allowlist.
• CI image lacks the backend binary → command errors or silently degrades. Mitigate by defaulting to wordlist and using a doctor-style command to assert backend and dictionary availability in CI.
• Locale mapping gaps → catalogues silently unchecked. The spellcheck:doctor concept should be ported; it exists precisely for this.
• Composer resolution breakage on framework upgrades → the dev dependency blocks a Laravel major bump. Cheap to fix (drop or repin) but needs to be on the upgrade checklist.
• Baseline drift → stale baseline hides new typos, or a regenerated baseline silently accepts them. Enforce baseline regeneration as a reviewed diff.

Ramp-up — Minimal for developers (a CI annotation and a "run this command locally" note). Non-trivial for the platform owner: understanding the core's API, the ICU/placeholder stripping semantics, and the report formats well enough to debug a surprising result. Budget a few days for the wrapper author and half a day of documentation and a team walkthrough. The tool's value is entirely contingent on keeping false positives near zero in the first month, so plan an explicit tuning window after the pilot rather than declaring done at green build.