Statamic Features Laravel Package

Product Decisions This Supports

• Modular feature architecture: Enables organizing Statamic addons and application features as self-contained modules with their own tags, fieldtypes, modifiers, scopes, actions, widgets, dictionaries, subscribers, update scripts, blueprints, fieldsets, routes, and control panel assets.
• Build vs buy for feature scaffolding: Reduces the need to build a custom feature loader for Statamic + Laravel projects. Useful when evaluating whether to standardize on laravel-features as the modularization layer versus maintaining bespoke registration code.
• Roadmap for addon/package development: Supports a product roadmap that includes reusable Statamic addons or domain modules, especially where multiple features must be independently developed, tested, and shipped.
• Control panel customization: The ability to register and publish CP assets per feature—including Vite builds—supports product decisions around white-labeling, branded admin experiences, and feature-specific UI delivery.
• Route separation and feature isolation: Loading routes/web.php, routes/cp.php, and routes/actions.php per feature supports decisions about feature ownership, access boundaries, and reducing route-file coupling.
• Ecosystem and platform leverage: Aligns with the Statamic + Laravel ecosystem and the laravel-features extension pattern, which can influence whether to invest in Statamic-native modularization or a more generic Laravel package structure.

When to Consider This Package

• You are building on Statamic and Laravel and want features/addons to own their Statamic registrations rather than centralizing them in a service provider.
• You already use or are evaluating laravel-features as a modularization pattern and need Statamic-specific integration.
• You need to package Statamic components—tags, fieldtypes, modifiers, scopes, actions, widgets, dictionaries, subscribers, update scripts, blueprints, fieldsets—inside feature modules.
• You want per-feature routes (web, cp, actions) and control panel assets, including a Vite build, without duplicating registration logic.
• You are building an internal modular monolith or a suite of Statamic addons where consistent feature scaffolding will reduce maintenance overhead.
• You can accept v1.0.0 maturity: this is the first stable release, so production adoption should include vetting, version pinning, and a fallback plan.

Look elsewhere if:

• You are not using Statamic or do not need Statamic-specific feature registration.
• Your project is a simple single addon or small site where the modular overhead is not justified.
• You require a long production track record or enterprise support guarantees; v1.0.0 is new.
• You prefer official Statamic addon conventions only and do not want an additional abstraction layer.
• Your team is not already comfortable with laravel-features or feature-oriented package structure.

How to Pitch It (Stakeholders)

For executives: This package lets teams ship Statamic features and addons as clean, reusable modules instead of scattered registration code. It can reduce duplication, speed up delivery of admin experiences and feature-specific routes/assets, and make it easier to maintain a growing Statamic product portfolio. The main caveat is maturity: v1.0.0 is a new stable release, so it is best adopted with version pinning and a small pilot before broad rollout.

For engineering: The release standardizes how a feature registers Statamic tags, fieldtypes, modifiers, scopes, actions, widgets, dictionaries, subscribers, update scripts, blueprint/fieldset namespaces, routes, and CP assets—including Vite builds. That means less boilerplate and clearer feature boundaries, but it also introduces a dependency on laravel-features conventions and an early-stage package. Recommended next step: pilot it in one internal feature or addon, verify asset publishing and route loading behavior, then decide whether to standardize.