Extraextra Laravel Package

Product Decisions This Supports

This package supports very few product decisions — and the most important one it does support is a "don't adopt" call. The evidence is thin and internally contradictory, which is itself the signal.

• Build vs. buy, resolved toward build. The package's own description is "the hottest news right in your Statamic dashboard" — a novelty dashboard widget that surfaces headlines for content editors. That is a few hours of Statamic-native work (a custom widget class plus a cached HTTP call), not a capability worth an external dependency. When internal build is cheaper than the review-and-upgrade overhead of a dependency, build.
• Dependency register inclusion (recommend: exclude). Last release was 2020-12-01, stars are 0, and the maintainer appears single-person. There is no evidence of ongoing maintenance, Laravel/Statamic major-version tracking, security policy, or issue responsiveness. Adding it expands the maintenance surface without expanding product capability.
• Roadmap relevance: negligible. This is an editor conveniences/quality-of-life item, not differentiator work. If editors genuinely want news in the dashboard, it belongs in a "polish" bucket, not a roadmap commitment — and even then, built in-house.
• Documentation-trust as a decision input. The supplied description.md claims Eloquent helpers, global helper functions, and publishable config, which directly contradicts the package's Statamic-dashboard-news description. The assessment-pm.md is generic boilerplate that does not describe this package at all. When the stated scope is unreliable, we cannot make an evidence-based fit call — and we should not adopt on documentation promises.
• Exit-cost planning as a standing rule. Any dashboard widget we ship should be our own code behind a small internal interface, so we can swap the news source or remove it without touching domain code. That is a product decision, because it caps downside and keeps a novelty feature from becoming load-bearing.

Limitation to state up front: the only release artefact available is 1.0.1, a documentation reorganisation — no functional changelog. There is no reliable evidence of what the package actually does at runtime, what Statamic/Laravel versions it supports today, or whether it installs cleanly on our stack. This assessment therefore governs how to decide, not feature-level fit; a fit call would require a hands-on spike against our actual environment.

When to Consider This Package

Consider it (narrowly) only when:

• You are on Statamic (not plain Laravel) and want a low-stakes, read-only news widget for the control panel — and you are willing to fork and maintain it yourself, treating it as reference code rather than a dependency.
• You want to see a working example of a Statamic dashboard widget before building your own — in which case read the source, don't composer require it.
• The capability is a novelty, sits far from anything customer-facing, and a broken install costs an afternoon, not revenue.

Look elsewhere — or build — when:

• Any production dependency is contemplated. Zero stars, no releases since December 2020, and a single maintainer mean no reasonable expectation of fixes, security patches, or compatibility updates.
• Your Statamic or Laravel major version has moved since 2020. It almost certainly has. An unmaintained addon is a recurring upgrade blocker for a feature nobody asked for.
• Documentation contradicts the product description. We cannot scope, test, or support what we cannot describe.
• It would touch a high-blast-radius path (auth, payments, PII, data integrity) — it should not be anywhere near those, and there is no security policy or review artefact published.
• The equivalent is a few dozen lines of framework-native code. It is. Build the widget in-house, cache the feed, and own it outright.
• You need vendor support, indemnification, or a security review artefact. None are published.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a Statamic dashboard widget that displays news headlines for content editors — a convenience, not a capability that affects customers or revenue. The project is a single-maintainer package with no releases since December 2020, no adoption signal, and documentation that contradicts its own description. My recommendation is not to adopt it as a dependency. If editors want headlines in the dashboard, engineering can build an equivalent widget in under a day, keep it inside our own codebase, and avoid inheriting an unmaintained third-party component. Cost of the alternative is a few hours; cost of the dependency is unbounded upgrade and security overhead for zero strategic return.

For engineering (the operational case): Treat the source as a reference pattern, not a dependency. The package is past 1.0 on paper, but the last release is three-plus years old and documentation-only, so there is no evidence of Statamic/Laravel version support on our current stack. The stated scope in the package metadata also conflicts with its description, so a compatibility spike would mostly be spent discovering what it does, not whether it helps. Building a small custom dashboard widget — a widget class, a cached HTTP fetch, and a thin internal interface so the feed source is swappable — takes roughly half a day and leaves us with code we can test, version, and remove cleanly.

The ask: Do not sponsor adoption. If the editor-facing news widget is genuinely wanted, approve a half-day timebox to build it in-house behind our own interface. Decision criteria are explicit: it stays a novelty widget outside any high-blast-radius path, it caches the upstream feed, and it is owned by our team. If the half-day overruns materially, we deprioritise the widget rather than revisit the third-party package.