thebatclaudio/eloquent-markdown
Add Markdown support to Eloquent models with a simple cast that converts stored Markdown into HTML for display. Keep raw Markdown in the database while serving clean, presentation-ready content in Laravel apps.
Upgrade sequencing and platform roadmap. v2.0.0 is a pure support-matrix release: no new features, no API changes, no deprecations in functionality. Its only effect is to make the package require PHP ≥ 8.3 and Laravel ≥ 12. That turns it into a hard gate in your framework-upgrade plan — it cannot be the package that holds you back, but it also cannot be adopted until the rest of the stack is already there. Sequence it after the Laravel 12 / PHP 8.3 migration, not as a driver of it.
Forward-looking support coverage reduces future churn. The constraint ^12.0|^13.0 already declares Laravel 13 compatibility. For planning purposes that buys you a skipped re-evaluation cycle — one fewer forced dependency review when Laravel 13 lands. Weigh this when comparing against alternatives that lag a major behind.
Build vs. buy (build vs. adopt). This remains a narrow, single-purpose utility (Eloquent → Markdown output). Nothing in this release changes the calculus: the scope is too small to justify in-house ownership, and the maintainer is clearly tracking upstream framework releases. Adopt and move on; do not allocate engineering time to a homegrown equivalent.
Maintenance-health signal, not a feature signal. The release also raises orchestra/testbench to ^10, larastan to ^3, and phpstan to ^2. That's a maintainer investing in the test and static-analysis harness alongside runtime support — a positive health indicator for a low-traffic dependency you'll otherwise not think about.
Risk to log: installed-base split. A major bump with zero functional change exists solely to move the compatibility floor. That is the right call, but it means v1.x is now effectively frozen. Any service still on Laravel 10/11 that pins ^1.0 sits on a branch that will stop receiving fixes and security patches. Enumerate those services and put them on the roadmap as dependency-at-risk, even if the package's own risk surface is small.
Migration effort: near-zero where unblocked, blocking where not. For projects already on PHP 8.3 / Laravel 12, the change is one line in composer.json and no code edits. For projects behind that line, there is no migration path in this release at all — only pinning and deferring.
Adopt v2.x when:
Stay on v1.x (and flag it) when:
^1.0 and treat it as a tracked risk with a dated exit.Look elsewhere when:
For executives (one line): A small, actively maintained open-source utility we use for Eloquent-to-Markdown output shipped a major version. It contains no functional changes — it simply raises the floor to PHP 8.3 and Laravel 12. No product impact; it's a scheduling item, not a decision.
For engineering leads: Upgrade is a one-line constraint change (^2.0) plus a composer update for any service already on Laravel 12 / PHP 8.3. Zero code changes required. Services still on Laravel 10/11 must pin ^1.0 and go on the "dependency at risk" list, because v1.x is now frozen upstream. The upside: v2 declares Laravel 13 support in advance, so we skip a future evaluation cycle.
The trade-off to state plainly: We are accepting a fast-major dependency cadence in exchange for zero-maintenance functionality and a maintainer who keeps pace with the framework. That's the right trade for a utility of this size — but it means each Laravel major now has a small, predictable follow-on task attached to it, and we should budget for that rather than be surprised by it.
Recommendation: No action required beyond adding the constraint bump to the Laravel 12 migration checklist and inventorying v1.x pins. Do not re-open build-vs-buy.
How can I help you explore Laravel packages today?