Demo Block Extension Laravel Package

Product Decisions This Supports

• Build vs. buy, resolved as "build": This package is not a capability you buy or depend on — it is a ~one-file reference implementation demonstrating how to author a block for the Anomaly Blocks module (PyroCMS/Streams ecosystem). Its only product value is as a working scaffold, so the decision it informs is "do we copy this structure into our own block extension?" rather than "do we adopt this package?"
• Scaffolding and onboarding speed: For a team standing up custom page blocks in an Anomaly/PyroCMS build, this gives an immediately runnable example of the required package layout — service provider registration, block class definition, views/fields, and composer wiring. That shortens the first-block time-to-value from a research spike to an afternoon.
• Roadmap input on content modeling: Because it shows the minimal contract a block must satisfy, it clarifies what a block can and cannot express, which feeds decisions about how much page-builder flexibility to expose to content editors versus hard-coding templates.
• Ecosystem lock-in signal: The package exists only inside the Anomaly Blocks abstraction. Reviewing it is a concrete way to evaluate whether the Blocks module's extension model is ergonomic enough to standardize on for a multi-site or CMS-driven product.
• Not a production dependency: With zero stars and zero dependents, it should never appear in a composer.json require block. Treat it as documentation that happens to be installable.

When to Consider This Package

Adopt (as a reference, not a dependency) when:

• You are actively building on the Anomaly/PyroCMS Blocks module and need a correct, minimal starting point for a custom block extension.
• You are doing a technical spike to estimate effort for a page-builder or modular-content feature and need to see the real shape of the extension contract.
• You are onboarding engineers who are new to the Anomaly module system and want a small, readable example rather than the full framework source.

Look elsewhere — or write your own from scratch — when:

• You need a block that actually does something in production. The package is explicitly an example; it has no feature surface, no tests of note, and no release history to lean on.
• You are not on Anomaly/PyroCMS. The package is meaningless outside that ecosystem; for vanilla Laravel, use Blade components, Livewire, or a Filament/Nova field package instead.
• Maintenance and security posture matter. Zero stars, zero dependents, and no community means no upstream fixes; any Laravel or PHP version drift is yours to absorb. Vendor or fork the pattern rather than requiring the package.
• You need support SLAs, documentation depth, or a migration path. None of those exist here — the upstream framework's docs are the real reference.

How to Pitch It (Stakeholders)

For executives: This is not a product component — it is the vendor's "hello world" sample for their block system. We are not buying anything or taking on a new dependency. Its value is that it de-risks a build decision: it shows our engineers exactly what a custom content block costs to produce, which lets us estimate page-builder work with real evidence instead of guesses. Cost of use is zero; cost of depending on it would be a maintenance liability, so we will copy the pattern, not the package.

For engineering: Treat anomaly/demo_block-extension as executable documentation for the Blocks module. Clone it, read the service provider and block class, then build our own extension with our own namespace, our own tests, and pinned Laravel/PHP constraints. Do not add it to require; do not build on top of it. If we standardize on Blocks, the first thing we do is turn this example into an internal scaffolding template we control, so upstream abandonment costs us nothing.