Statamic Peak Commands Laravel Package

Product Decisions This Supports

• Build vs. buy on internal scaffolding. A make:partial generator is the kind of thing teams hand-roll in a base repo or an internal artisan command. This package replaces that custom tooling with a maintained dependency, so the decision is really "do we keep owning our generator?" rather than "do we adopt a framework feature?"
• Convention-setting for front-end assets. v11.1.0's optional CSS file generation turns a code-generation convenience into a lightweight styling convention: new partials can arrive with their stylesheet already created and imported. That is a product decision about whether styles live with components or in a separate global layer — worth settling once, centrally, instead of per-team.
• Onboarding and time-to-first-PR. Generators shorten the path from "new hire" to "shipped component." If your roadmap depends on ramping contributors onto a Blade-heavy codebase, generator ergonomics are a real (if unglamorous) lever.
• Design-system rollout sequencing. If you plan to introduce or refactor a component library, a generator that emits component + styles together makes the migration cheaper to parallelize across squads.
• Not a roadmap input. This is an opt-in convenience flag. It should not move a delivery date, and it should not be sold internally as a capability — it's developer-experience polish.

When to Consider This Package

Consider it when:

• The codebase is Blade/view-heavy and contributors repeatedly create partials by copy-pasting existing files.
• You want styling co-located with view partials and are willing to standardize on the generator's output shape.
• You already have (or want) a house convention for component scaffolding and would rather configure a package than maintain an internal artisan command.
• Your team is small enough that a breaking change in a generator costs hours, not a sprint — i.e., the blast radius of the dependency is contained to developer tooling, not runtime behavior.

Look elsewhere or skip it when:

• Your front-end is dominated by a JS framework or a component system with its own first-class generators (Inertia/React/Vue, Livewire, etc.) — a partial generator plus CSS emission may duplicate or conflict with existing tooling.
• You have an established internal generator with team-specific opinions (naming, test stubs, storybook files). Migrating buys little and costs re-training.
• You rely on a CSS pipeline where per-component files are an anti-pattern (single bundled stylesheet, CSS-in-JS, utility-first with no per-component files). The new CSS flag would be a footgun rather than a help.
• You need guarantees on long-term maintenance. A single-maintainer package at v11 with narrow scope is low-risk to try, but don't make it load-bearing for the build without an exit plan.

How to Pitch It (Stakeholders)

To executives: This is a small, low-cost developer-experience dependency, not a platform bet. The latest release adds an option to scaffold a stylesheet alongside newly generated view partials, which nudges the team toward a consistent component-and-styles pattern and trims the manual steps in creating new UI pieces. Expected benefit is modest and cumulative: less boilerplate, fewer copy-paste inconsistencies. Risk is contained because the package sits in developer tooling rather than in the request path — if it goes stale, we remove it without touching production code. Recommend a trial on one squad before any org-wide convention.

To engineering: v11.1.0 adds an opt-in flag to generate a CSS file and wire up its import for components created via make:partial. It's backward compatible — existing generation behavior is unchanged unless the flag is used. Two things to decide before adopting: (1) whether per-partial CSS files match our pipeline, and (2) whether we standardize the flag on by default in the base repo so output stays consistent across teams. If we do neither, the upgrade is a no-op and safe to take.