Read Time Laravel Package

Product Decisions This Supports

• Content UX feature decisions: Whether to display a "X min read" label on articles, blog posts, changelog entries, knowledge-base articles, or docs. This is a low-cost engagement/expectation-setting feature that helps users decide whether to start reading now or save for later.
• Roadmap prioritization for content surfaces: If read-time is a cheap win for the blog/docs vertical, it can be sequenced ahead of larger content investments (recommendations, personalization, reading lists) as a fast, visible improvement with near-zero infrastructure cost.
• Build vs. buy: The honest answer is neither — this is a ~30-line calculation (strip HTML, count words, divide by words-per-minute). The decision is really "adopt a maintained convention vs. write it ourselves." Adopt only if the HTML-stripping edge cases and Laravel ergonomics save more time than the dependency costs. Update from the 2.0.0 release: the maintenance argument just got more complicated, not simpler. A major-version bump is evidence someone is still shipping, but with no published release notes we cannot say what shipped — so the build-vs-buy calculus now includes an unbudgeted "validate a major upgrade" cost.
• CMS/editorial workflow decisions: Read time can be surfaced in the authoring UI as an editorial signal ("this draft is a 14-minute read — consider splitting"), supporting content-length governance and readability standards.
• Audience segmentation experiments: The words-per-minute constant is configurable, so PMs can test audience-specific estimates (e.g., technical docs at 150 WPM vs. marketing content at 220 WPM) and measure whether calibrated estimates improve completion rates or reduce bounce.
• Localization and accessibility planning: Read time supports accessibility goals (cognitive load, time-to-consume expectations) and informs whether we need per-language calibration — which this package does not provide out of the box.
• Dependency-adoption governance: This is now a small test case for how we adopt any dormant-then-revived package: pin the version, read the diff, wrap the API, own the escape hatch. Useful precedent beyond this feature.
• Not supported: Anything requiring analytics, personalization infrastructure, TTS/read-aloud duration, or per-user reading-speed modeling. Those are separate roadmap items.

When to Consider This Package

Consider it when:

• The stack is Laravel or plain PHP and you want a helper-style API (read_time($content)) with no service, no API key, no config sprawl.
• You need a fast, good-enough estimate for HTML content and don't want to own the regex/strip-tags logic yourself.
• The surface is non-critical: a label on a card or article header. If it's wrong by 30 seconds, nobody is harmed.
• You want MIT-licensed, forkable code with a tiny surface area — the risk of "abandoned package" is mitigated by the fact that you could reimplement or vendor it in an afternoon.
• You're validating the feature before investing: ship the label, measure engagement, then decide whether to build a first-party calculator.

Look elsewhere (or build in-house) when:

• You need multilingual accuracy. Word-count-based estimators break down for Chinese, Japanese, and Korean, where character-based counting is required. If i18n content is on the roadmap, plan a custom implementation.
• You need content-aware estimation. Code blocks, images, tables, and embedded video all change real reading time. This package counts words; it doesn't model media.
• You need per-user or per-content-type calibration at scale, A/B testing of WPM, or read-time as a ranking signal — that's a data problem, not a string-utility problem.
• You're not on PHP/Laravel, or you need the estimate computed client-side for dynamically rendered content.
• You can't absorb an unannounced upgrade right now. See below.

Changed by 2.0.0 — read before adopting:

• No release notes were published for 2.0.0. A major-version bump on a package that was dormant since January 2021 is a signal, but an unlabeled one. Treat it as a breaking change by default until someone reads the changelog and the diff. Do not composer require this on a Friday.
• Prior assessment said "last release January 2021; accepting a dormant dependency." That statement is now stale and must not be repeated to stakeholders. The accurate statement is: "one new major release, contents undocumented as of writing." Those are different risk postures and only one of them is defensible.
• Two plausible readings, and we should plan for both. Either (a) the package is being revived — PHP/Laravel version constraints raised, modernized internals, possibly a changed namespace or helper signature; or (b) it's a housekeeping major version (dependency bumps, autoload changes) with no behavioral change. Until verified, assume (a): pin to a known-good version, budget a half-day for the upgrade, and confirm the PHP and Laravel version floors match our runtime.
• This validates the wrapper recommendation, not weakens it. The original pitch asked engineering to hide the package behind our own ReadTimeCalculator interface. A surprise major version is exactly the scenario that justifies it — so adopt the pattern, and pin ^2.0 deliberately rather than floating.
• The escape hatch is still cheap. Nothing here changes the core fact that this is a ~30-line calculation. If the 2.0.0 diff turns out to be invasive or the package goes quiet again, reimplementing in-house remains an afternoon of work. The dependency is a convenience, not a commitment.

How to Pitch It (Stakeholders)

For executives (30 seconds): We can add a "5 min read" label across our content surfaces in under a day, using a small MIT-licensed open-source library. It's a low-risk, low-cost UX polish item that sets reader expectations and gives us a cheap experiment to measure against engagement metrics. It is not a strategic capability — treat it as a tactical win, not a platform investment. If the experiment shows value, we can replace it with a first-party calculator later without any user-visible change. One caveat to flag honestly: the library shipped a new major version with no published changelog, so I'm asking engineering for a short validation pass before we commit. That's a couple of hours, not a blocker, and the fallback (writing it ourselves) is still trivially cheap.

For engineering (the real pitch): One composer require, one helper call, and a thin wrapper. I'm asking you to:

1. Read the 2.0.0 changelog and diff first. It's a major version on a package that hadn't shipped since January 2021, and the release notes are empty. Confirm what broke, what the new PHP/Laravel version floors are, and whether the helper signature or namespace changed. If the diff looks invasive, tell me — building it in-house is a legitimate answer and I'd rather know now.
2. Wrap the call behind our own ReadTimeCalculator interface rather than calling the package directly from views, so we can swap implementations (multilingual, media-aware, or in-house) without touching templates. The undocumented major version is the argument for this, not against it.
3. Pin the version constraint explicitly rather than floating, and add a test that pins expected output for a known fixture — so the next surprise major is verifiable in one CI run instead of a manual QA pass.
4. Note the caveats in the ticket: release history is dormant-then-revived with an undocumented major, English-centric word counting, no media weighting.

For design/content: Estimated read time appears wherever we show content previews — article headers, index cards, email digests. Copy should be consistent ("6 min read"). We'll calibrate the words-per-minute value after we see real completion data rather than guessing up front. Nothing in the 2.0.0 release should change what users see.

Bottom line: Still adopt as a tactical, swappable utility — not as infrastructure. The cost of coupling to it remains the thing to manage, and the 2.0.0 release with no changelog is a concrete reminder of why: pin it, wrap it, test it, and keep the in-house rewrite on the shelf.