Fm Summernote Bundle Laravel Package

Technical Evaluation

Architecture fit — unchanged: poor for a Laravel codebase. The 1.0 release is a Symfony modernization milestone, not a framework-bridging one. The substance of the changelog is Symfony 5/6 alignment (Symfony5 changes #29, Updates for sf6 #37, Add symfony bundle config #32) plus dependency automation (Upgrade to GitHub-native Dependabot #30, symfony-dependency-injection-test ^6.1 #45). Nothing in the release introduces a Laravel service provider, Blade directive, or any decoupling from Symfony primitives. The architecture remains:

• A bundle class plus a DI Extension that loads service definitions and a configuration tree — now formally published as bundle config in config/, which deepens rather than reduces the Symfony coupling.
• Integration with the Symfony Form component (SummernoteType).
• Twig template rendering (init.html.twig is touched directly in this release, confirming the templating surface is still Twig).
• Symfony asset/asset-mapper patterns for Summernote's JS/CSS.

What 1.0 actually changes for us:

Integration feasibility — unchanged: extraction only. The 1.0 tag improves install-ability on Symfony 6 stacks, which is irrelevant to a Laravel composer.json. Installing still means dragging Symfony Config, DependencyInjection, Form, and Twig into a Laravel container for one form widget. The realistic path remains treating the repo as a reference implementation and reimplementing in Blade + Vite — and 1.0 slightly improves that path by documenting a cleaner, current config schema to copy.

Technical risk:

Key questions (revised):

1. Does 1.0 bump the bundled Summernote version, or only the Symfony glue? The notes mention jQuery 2.x compat and no Summernote upgrade — if assets are still pinned to an older Summernote line, the "reference implementation" value drops too.
2. Which exact PHP/Symfony constraint set does 1.0 declare, and is there any branch where a Laravel-compatible resolution exists without --ignore-platform-reqs?
3. Is the language config option wired through to Summernote's i18n files, or does it only set a string? If assets aren't shipped, we must source locale files ourselves regardless.
4. What does "custom front" (#15) expose — a full template override hook (Twig-only, non-portable) or a config array we can lift into a Blade component?
5. Are the contributors in this release (systemasis, RaphaelSalique, mertoksuz, scoudxtr) ongoing maintainers or one-off drive-by patches? The bus-factor question is the one 1.0 does not answer.
6. Unchanged and still blocking: what is our server-side sanitization standard and CSP posture for inline editor assets?

Integration Approach

Stack fit — unchanged: mismatch, with the same narrow salvage path. Laravel's idiomatic answer remains npm install summernote + a Vite entry + a Blade component + a FormRequest validation rule. The 1.0 release does not create a Laravel path; it makes the Symfony path more current, which is orthogonal to our roadmap.

Recommended approach — extract, don't install (now with a better config source):

1. Treat as reference only. Still do not add to composer.json. 1.0 gives us a cleaner config schema to harvest than 0.2 did — lift the option set (toolbar, height, language, airMode, base_path/asset base, custom-button definitions) into config/summernote.php, using the new base_path naming so we don't inherit the deprecated key.
2. Reimplement the front end natively. resources/js/components/summernote.js initializes the editor; <x-summernote name="body" :value="$post->body" /> renders and initializes. Assets through Vite. Treat the release's jQuery 2.x compatibility work as a warning: pin a current Summernote major and verify it against our jQuery-free or modern-jQuery front end.
3. Own persistence and sanitization. Allow-list sanitizer before storage; {!! !!} only on sanitized content. 1.0 adds nothing here — no security-relevant entries in the changelog at all.
4. Adopt the two genuinely good ideas. Per-project language config and a "custom front" escape hatch are worth having; implement the latter as a Blade slot, not a Twig block override.
5. Keep the abstraction thin. Build a shared component only at the third consumer.

Migration path if the Symfony bundle is already in use. 1.0's basePath → base_path rename is the migration hazard: any existing Symfony-side config (or internal documentation copied from 0.2) must be renamed. If we are porting from Symfony to Laravel, capture the 1.0 config as the frozen baseline, then stand up the Blade/Vite equivalent in parallel and shadow-compare sanitized output on a record sample before cutover. Do not bridge by running the bundle inside Laravel.

Compatibility: 1.0 raises the Symfony ceiling, which is irrelevant to us but does mean the package now targets PHP 8-era runtimes — confirm it doesn't force a constraint our Laravel app would inherit transitively (another reason not to install). Separately, verify the Summernote and jQuery versions the bundle now assumes; jQuery 2.x support implies it tolerates a 2013-era jQuery, not that it ships a current editor.

Sequencing (largely unchanged, one step reprioritized):

1. Confirm editor requirements (toolbar, paste, media handling, i18n — now informed by the 1.0 language feature).
2. Spike native summernote + Vite + Blade component (1–2 days).
3. Define sanitization allow-list and validation rules.
4. Port the 1.0 configuration schema as documentation, normalized to the base_path naming.
5. Verify the current Summernote release against our CSS framework (Bootstrap vs Tailwind is still a real constraint).
6. Close out with a written "do not adopt" decision, now explicitly noting that 1.0 is a Symfony-maturity release with no bearing on framework fit.

Operational Impact

Maintenance. 1.0 modestly improves the maintenance story for Symfony users: Dependabot is native, Symfony 6 is supported, and dependency-injection tests were updated. For us, adopting it still means owning a Symfony-shaped dependency inside a Laravel app where no other Symfony code exists. The native path keeps our surface at one npm dependency plus a Blade component. Note the release cadence is dominated by StyleCI/typo/README commits — the package is being tidied, not actively developed, so bug absorption still falls to us.

Support. Bus factor is unchanged and is now the dominant risk: 1.0 adds four first-time contributors, but their contributions are typo fixes, a bracket fix, a config rename, and a language option — not evidence of a sustained maintainer bench. There remains no Laravel community, no Stack Overflow trail for this bundle in a Laravel context, and no upstream audience that would surface our integration bugs. Contrast with summernote itself.

Scaling. Unchanged: the editor is a per-request client-side asset with no meaningful server scaling dimension. The scaling-relevant decision is still payload — enforce image upload to object storage instead of inline base64, and cap stored HTML length. Independently, the jQuery 2.x compatibility work hints at legacy client-side assumptions; confirm the bundle isn't steering us toward an old jQuery to satisfy a front-end stack we don't have.

Failure modes:

Ramp-up. Near zero for the native path. Non-trivial for the bundle path and unchanged by 1.0 — a developer must understand Symfony bundles, DI extension config trees, and the Form component to debug it inside Laravel, knowledge the team has no other reason to hold. 1.0's cleaner bundle config actually increases the amount of Symfony-specific configuration a newcomer must read.

Verdict — non-adoption stands, with the rationale updated. The 1.0 tag is a real milestone but a framework-internal one: Symfony 5/6 support, Dependabot, issue templates, and two modest features (language, custom front). It does not move the package toward Laravel, does not address sanitization, does not refresh the underlying editor assets, and carries an unlabelled breaking config rename behind a semver jump — which slightly lowers confidence in future upgrade predictability. The correct TPM action is still a documented non-adoption: cite the unchanged framework mismatch, the orphaned dependency profile that 1.0 only cosmetically improves, and the fact that the security-critical layer lives outside the package. Harvest the 1.0 config schema (including language and the base_path naming), build the 1–2 day native equivalent, and spend the saved effort on sanitization and media handling — the parts that actually determine whether the feature is safe in production.