Bedrock Commands Laravel Package

Getting Started

• Install the package with Composer alongside its base Bedrock dependency, then publish the two new tags so the commands are customisable from day one:

  composer require <vendor>/bedrock-commands
  php artisan vendor:publish --tag=bedrock-commands-config
  php artisan vendor:publish --tag=bedrock-commands-stubs
  

• Look first at the published config file — it is the map of where sets live (blocks.yaml, article.yaml), where fieldsets and views are written, and what naming/stub conventions the commands assume. Getting these paths right is what makes every other command "just work".
• First use case: scaffold a new set with php artisan make:bedrock-set, which appends the set to the correct YAML field, generates its fieldset definition and creates its Blade view in one step. Commit all three artefacts together — that triad (YAML entry + fieldset + view) is the unit of work in this package.

Implementation Patterns

• Scaffold, then edit. Treat make:bedrock-block / make:bedrock-set as generators only. Run them, review the diff to confirm the YAML insertion point and view path, then fill in the fields. Avoid hand-editing the YAML for new sets unless you have a reason — inconsistent indentation and ordering is the main source of breakage.
• Use rename:* for refactors, not find-and-replace. When a set name changes, rename:bedrock-set updates the YAML, renames the fieldset and view, and rewrites every entry that stored that set — a manual rename across a database is error-prone and easy to leave half-done. Use the optional group-move flag in the same operation when you are reorganising which field a set belongs to.
• Use delete:* as the inverse of make:*. Removing a set should always be a single command so the field entry, fieldset file, view and stored entry data are all cleaned up together. Pair it with a review of any Blade templates that referenced the view directly.
• Version-control the YAML aggressively. These files are the schema of your content. Keep small, single-purpose commits per set so conflicts in blocks.yaml / article.yaml are resolvable, and so rename/delete diffs are easy to audit in review.
• Customise via stubs for house style. If your team uses a base layout, a particular namespace, or a standard set of wrapper attributes, edit the published stubs rather than the package files — every subsequent make:* will inherit your conventions.
• Wire it into your deploy/CI ritual. Any command that touches stored entry data (rename, delete) is a data migration in disguise; run it as an explicit, reviewed step against a fresh database dump, not as part of a routine artisan batch.

Gotchas and Tips

• delete:* and rename:* mutate stored content. They remove values from all entries and rewrite references respectively. Take a database snapshot, run against a staging copy first, and confirm the command reports what it changed before pointing it at production.
• Rename is not reversible. The old name is not kept as an alias; rollback means re-running the rename in reverse or restoring from backup. Note the old name in the commit message.
• Config caching bites path changes. After publishing or editing bedrock-commands-config, run php artisan config:clear (or re-cache) — otherwise the commands may keep writing fieldsets and views to the old locations, silently creating duplicates.
• Stub drift on upgrade. Published stubs shadow the package defaults, so new options or structural changes in a future release will not appear in your generated sets until you diff your stubs against bedrock-commands-stubs and republish selectively.
• Naming is the contract. Set names typically map to fieldset class names, view file names and YAML keys. Follow the package's casing convention exactly (kebab-case slugs, studly class names); a rename with odd casing can leave the view and fieldset out of sync with the reference.
• Group moves require the target to exist. When moving a set to another group/field during rename, confirm the destination field is already defined in the YAML — the command updates references but won't invent a field definition for you.
• YAML churn. Generators append to the file, which can reorder or reformat surrounding content depending on your YAML writer. Diff carefully; if reviewers see unrelated reformatting, isolate the generator output into its own commit.
• Debugging a failed run: check the config paths first, then the YAML for syntax validity, then whether entries actually contain the set key (e.g. entries saved before the set existed won't be touched). Re-running a partially applied command is usually safe for make:*, but verify state by hand after any interrupted rename/delete.