Markitup Bundle Laravel Package

Technical Evaluation

Architecture fit. This is a Symfony2 bundle, not a Laravel package — the mismatch is structural, not cosmetic. sonata-project/markitup-bundle ships a Bundle subclass, DependencyInjection/ extension, Resources/config/ service XML, an Assetic asset pipeline hook, and a Twig form theme. Laravel has no AppKernel, no bundle registration, no Assetic, and no Twig. Adoption therefore means either (a) installing it as a dependency and writing a shim layer that boots Symfony's DI container inside a Laravel app, or (b) treating it as a reference implementation and porting its ~200 lines of form-type/asset wiring into a Blade component and a Vite entry point. Option (b) is the only realistic path.

What the package actually is matters here: markItUp is a jQuery toolbar widget that decorates a <textarea> with buttons and a preview pane. It is not a Markdown parser, not a validator, and not a storage layer. Any Laravel integration still needs a server-side renderer (league/commonmark) and its own sanitization. The bundle's real value is a curated set of button/toolbar definitions and a preview-pane convention — recoverable from the repo in an afternoon.

Integration feasibility. Composer resolution is a hard blocker before any code is written. The package's constraints target Symfony 2.x era components and pull sonata-project/admin-bundle; a modern Laravel application depends on Symfony 6/7 components via illuminate/*. Those constraints cannot co-resolve, so composer require either fails outright or forces a dependency downgrade across the framework — unacceptable. A --ignore-platform-reqs install buys a package that will not autoload correctly.

Technical risk.

• Abandoned and archived. No security response process, no advisory triage, no path to a patch. Any CVE in the transitive tree is yours to fix via fork.
• EOL framework substrate. Symfony 2.8 reached end of life in November 2018; the bundle's own support window closed before that.
• Unmaintained front-end dependency. markItUp itself is a jQuery-era library last released around 2014. jQuery is an extra ~90KB you likely do not otherwise ship, and markItUp's preview rendering and inline onclick-style init are hostile to a strict Content-Security-Policy.
• XSS surface. Client-side preview panes that inject rendered HTML are a classic stored-XSS vector. There is no maintained sanitizer in this stack and no upstream to fix one.
• Zero ecosystem signal. 1 star, 0 dependents, archived. There is no third party who has validated this path, so every integration question is answered by reading source.

Key questions for the requester.

1. Is there an existing Symfony2/Sonata application being ported to Laravel, or is this a greenfield editor requirement? The answer changes this from "extraction exercise" to "irrelevant."
2. Which markItUp sets are actually in use — Markdown, HTML, Textile, Wiki? Textile and Wiki have no maintained modern equivalent and would need custom toolbar config.
3. Is the requirement a rich-text toolbar, or Markdown authoring? A toolbar can be met by EasyMDE, CodeMirror 6, or Toast UI in a single Blade component with no porting at all.
4. Does the security review accept a jQuery dependency and a relaxed CSP for the editor route?
5. Who owns the fork when a vulnerability is disclosed — is there a named engineer and a patching SLA?

Integration Approach

Stack fit. Poor as a dependency, moderate as source material. Treat the repository as a specification, not a library: vendor the markItUp JS/CSS assets and the set definitions into resources/js/vendor/markitup/, and discard the PHP entirely. This is the only sequence that does not poison composer.json.

Migration path.

1. Inventory. Grep the legacy codebase for markitup, markItUp, and the form type/service IDs. Record every textarea that uses the widget and which set (markdown, html, textile) it configures. If there is no legacy Symfony app, stop here — the package is not applicable.
2. Lift assets. Copy Resources/public/ (JS, CSS, set definitions, skins) into the Laravel asset tree. Record the original commit SHA in a PROVENANCE.md so future maintainers know the source is frozen.
3. Replace the pipeline. Assetic does not exist in Laravel. Register the assets as a Vite entry (resources/js/editor.js) and import markItUp plus jQuery there. Prefer installing markItUp's npm distribution if a pinned version is published, so the vendor copy has a version string.
4. Replace the form theme. The Twig form theme becomes a Blade component: <x-markdown-editor name="body" :value="old('body', $post->body)" />. The component renders the textarea, the toolbar container, and a data-set attribute. Initialization moves from inline script to a data-*-driven module in the Vite bundle, which keeps CSP compliant via nonce or hash.
5. Replace server-side concerns. Nothing in the bundle parses Markdown. Add league/commonmark plus an HTML sanitizer (symfony/html-sanitizer or mews/purifier) and render on the server. Do not trust the client preview output as canonical.
6. Cut over. Feature-flag the component per route, shadow-compare rendered output against the legacy editor for one release cycle, then delete the legacy path.

Compatibility. Requires jQuery at a version markItUp was tested against (1.7–1.11 era); modern jQuery 3.x mostly works but the toolbar's IE-era feature detection is dead code. If the app already ships jQuery 3.x for other reasons, the marginal cost is markItUp's ~20KB; if not, adding jQuery for one textarea is a poor trade and should push you to a framework-agnostic editor.

Sequencing. Do the dependency-conflict spike first — a 30-minute composer require --dry-run in a scratch branch will confirm the co-resolution failure and end the "just install it" conversation before anyone plans around it. Only then commit to the extraction path, and only if step 1 found real legacy usage.

Operational Impact

Maintenance. Total. The upstream is archived and receives no commits, so every future jQuery bump, bundler change, CSP tightening, or browser API deprecation lands on your team. Budget this as a permanently forked internal asset, not a dependency. The one mitigating factor is size: the PHP surface is small enough that a competent engineer can read all of it in an hour, and the extracted front-end is essentially static.

Support. No vendor, no maintainer, no issue tracker that will respond, one star and zero dependents meaning no community to consult. Internal Slack archaeology is the support channel. This is acceptable for a frozen toolbar widget and unacceptable if anyone believes they are consuming a supported editor.

Scaling. Server-side cost is nil — this is entirely client-side rendering. The concerns are payload (~90KB jQuery + ~20KB markItUp + skins, uncompressed) on every editor route, and the preview pane rendering on the main thread for large documents. Neither is a scaling ceiling; both are page-weight regressions against a modern editor at roughly a third the size.

Failure modes.

• Silent asset breakage on upgrade. Vite major bumps, jQuery removal from a shared bundle, or a CSP header added by the security team will blank the toolbar with no server-side error. Needs a smoke test asserting the toolbar container is populated.
• Composer lock poisoning. If anyone does force the bundle in, subsequent composer update runs fail or downgrade Symfony components under Laravel, producing confusing framework-level errors far from the cause.
• XSS via preview. The highest-severity failure. Sanitize server-side and treat the client preview as untrusted decoration.
• jQuery version drift. A global jQuery upgrade for an unrelated feature can silently break markItUp's plugin registration order.
• Knowledge loss. No upstream docs survive the archive; the only accurate documentation is the vendored source and your own PROVENANCE.md.

Ramp-up. Low in absolute terms, high relative to the payoff. A mid-level engineer unfamiliar with either Symfony2 or markItUp needs roughly a day to read the bundle, understand the set configs, and produce a working Blade component — most of that spent on Symfony conventions they will never use again. The extracted result is maintainable by anyone who knows jQuery. The real ramp-up risk is organizational: a future engineer discovering markitup in the codebase will search for it, find an archived repo with one star, and escalate. Write the ADR at extraction time, not later.

Recommendation. Do not adopt as a dependency under any circumstances — the Composer conflict and the archived status are each independently disqualifying. If a legacy Symfony2 application is genuinely being migrated and its authors depend on this specific toolbar behavior, extract the assets and accept a small, bounded, permanently-forked widget. If the requirement is simply "a Markdown editor," EasyMDE or CodeMirror 6 in a single Blade component delivers more capability, current maintenance, no jQuery, and CSP compatibility in less time than the extraction.