Bedrock Commands Laravel Package

Technical Evaluation

Architecture fit: v1.0.0 positions the package as a development-time Laravel Artisan toolchain for managing YAML-defined blocks/sets and their generated fieldsets/views. It fits projects already using a blocks.yaml / article.yaml convention, likely in a Bedrock/Sage-style WordPress stack or similar Laravel-adjacent CMS workflow. It is not a runtime dependency; value comes from scaffolding, renaming, and deleting block/set definitions consistently across config, fieldsets, views, and entry data. Fit is low for standard Laravel applications without that schema.

Integration feasibility: Feasible as a Composer require-dev package. The new make:*, delete:*, and rename:* commands cover the full lifecycle of block/set management, and publishable config/stubs (bedrock-commands-config, bedrock-commands-stubs) make local convention customization possible. Integration depends on confirming supported Laravel/PHP versions, expected project paths, and compatibility with existing Bedrock/Sage/ACF conventions.

Technical risk: Moderate. Delete and rename commands mutate YAML, files, and entry data, so partial failures could leave projects inconsistent. The release notes do not mention dry-run mode, confirmation prompts, backups, transactionality, or rollback. YAML serialization and merge conflicts are also operational risks. v1.0.0 is a first stable baseline, but destructive command behavior should be validated in isolated branches before team-wide adoption.

Key questions:

• Which Laravel, PHP, Bedrock/Sage, and ACF versions are supported?
• Do delete:* and rename:* support dry-run, confirmation, backups, or rollback?
• Are file/YAML/entry mutations atomic and idempotent on failure?
• How are entries matched during rename/delete, especially with multisite or localization?
• Are project paths, YAML filenames, and stub locations configurable?
• Is there an upgrade path when published config/stubs diverge from package defaults?

Integration Approach

Stack fit: Adopt as a dev-only tool for projects using YAML-driven block/set definitions. It should run in local development or controlled CI environments, not in production runtime paths.

Migration path: Establish a baseline of existing blocks.yaml / article.yaml, fieldsets, views, and entry data. Add the package as a dev dependency, publish config and stubs, compare generated output against current conventions, then pilot make:* on a new block/set in a feature branch. Test rename:* and delete:* only against disposable branches or seeded environments first.

Compatibility: Validate PHP/Laravel support and confirm the package’s assumed project structure matches the repo. If stubs or paths differ, customize published stubs/config rather than patching vendor files. Avoid mixing manual and generated edits without documenting ownership.

Sequencing:

1. Confirm package compatibility and project conventions.
2. Install as dev dependency and publish config/stubs.
3. Run make:bedrock-block / make:bedrock-set in a sandbox branch.
4. Pilot rename:bedrock-set with backup and diff review.
5. Pilot delete:bedrock-set only with recoverable data.
6. Add linting/CI checks for YAML and generated file consistency.
7. Document team usage and rollback procedures before rollout.

Operational Impact

Maintenance: Low runtime maintenance, but published config/stubs become project-owned artifacts and must be kept in sync with package updates. YAML, fieldset, view, and entry consistency becomes an ongoing hygiene concern.

Support: Support burden is mostly developer onboarding and command usage rather than production operations. Teams need clear guidance on destructive commands, backups, and review workflows.

Scaling: Improves developer throughput as block/set count grows, but large rename/delete operations may be slow or risky across many entries. Multisite and localized content could increase complexity significantly.

Failure modes: Partial command failure can leave YAML, fieldsets, views, and entries out of sync. Delete can remove data unrecoverably. Rename can miss references or create orphaned files. YAML merge conflicts and path/config drift are likely in active repos. Without dry-run or transactional guarantees, recovery depends on version control and database backups.

Ramp-up: Low for Laravel/Artisan users; moderate for teams unfamiliar with YAML-driven block/set schemas. Require a short runbook covering backups, branch isolation, diff review, and rollback before enabling delete/rename commands broadly.