Laravel Craftsman Laravel Package

Product Decisions This Supports

• Feature delivery speed / time-to-demo. Craftsman is a scaffolding layer: one command emits the full vertical slice for a resource — model, migration, controller, request/validation, resource or view, factory, seeder, and test stub — instead of five to eight manual artisan make: calls plus hand-wiring of namespaces and paths. The PM decision it informs is "how fast can we put a working CRUD screen in front of a stakeholder," which is often the real constraint on validating an internal tool or MVP. As of 1.10.1 the test stub can be emitted in Pest syntax (craft:test --pest, optionally --unit), which removes a manual rewrite step for teams that standardised on Pest rather than PHPUnit — but note the option was added in July 2020, so it targets Pest 0.x-era conventions, not Pest 2/3.
• Build vs. buy (buy = adopt, build = write our own stubs). The package is effectively an opinionated set of Laravel stubs plus a naming/path convention engine. That makes it a direct comparison point against (a) native artisan stub:publish + custom stubs, and (b) a 1–2 day internal generator. Decision: adopt as a disposable accelerator, or reimplement the 20% of conventions we actually use.
• Roadmap sequencing for CRUD-heavy surfaces. If the roadmap is dominated by admin panels, back-office tooling, tenant onboarding flows, and internal dashboards — work that is 80% repetitive resource plumbing — scaffolding throughput is a lever on the release plan. If the roadmap is API-first with heavy domain logic and few resources, the lever is negligible.
• Standardization and onboarding. A generator enforces one file layout and naming convention across the team, which is a real PM-visible outcome: fewer review comments about structure, faster ramp for new hires, more predictable PR diffs. Testing-framework choice is part of that convention, and 1.10.1 makes Pest a first-class option rather than a post-generation edit.
• Not a runtime dependency. This is a dev-time tool; it does not ship to production, does not add attack surface, and cannot cause an outage. That materially lowers adoption risk and should be reflected in the decision framing — the downside of trying it is a wasted afternoon, not a production incident. The 1.10.1 fix set (see below) is a reminder that the output, not the tool, is what reaches production, so generated code must be reviewed like hand-written code.
• Reference artifact for an internal DX roadmap. Even if not adopted, it is a cheap, MIT-licensed catalogue of what a scaffolding tool should generate and which flags matter — including a worked example of test-framework selection as a generator flag. Useful input if we ever invest in a proper internal developer-experience toolchain.

When to Consider This Package

Consider it when:

• The application is on a Laravel version the package actually supports (last release 3 July 2020, so realistically Laravel 6/7-era conventions). Verify by generating one resource into a throwaway branch and reading the output — do not trust the README alone. The 1.10.1 changelog is a concrete argument for that discipline: craft:migration was emitting protected $tablename instead of protected $table for the CreateXXXTable class name until this patch, i.e. the generator produced silently wrong model code for an unknown number of prior versions.
• The near-term work is a burst of resource-shaped features: prototypes, hackathons, internal tools, proof-of-concepts, migration of spreadsheets into a small admin app.
• The team wants a convention imposed cheaply and is willing to fork and vendor it, treating our copy as the source of truth rather than upstream.
• You need the scaffolding only; you are happy to hand-edit the generated output immediately after (it is a starting point, not a maintained abstraction). Budget review time for generated files accordingly — a generator that can ship a wrong property name is a generator whose diff you read.

Look elsewhere when:

• You are on Laravel 9/10/11+ or PHP 8.2+. The last release is July 2020 — 1.10.1 did not change that — and there are zero dependents on Packagist. Those remain the two most reliable signals that nothing is being smoke-tested against modern framework versions. Expect stub drift around typed properties, attributes, enums, and changed directory conventions, and expect to fix generators rather than features.
• You require anything resembling a maintenance guarantee: security review, support SLA, vendor accountability, or a commit history this decade. There is none. A patch that fixes a wrong generated property name, shipped with no follow-up release in five years, is the shape of the risk.
• Your team is small and already fluent in artisan make: and stub:publish. The marginal gain over native stubs is modest, and native stubs never break on upgrade.
• You are building a long-lived product where generated code becomes load-bearing and the team later cannot distinguish "craftsman convention" from "our convention."
• You want batteries-included scaffolding (auth, teams, billing) — that is Breeze/Jetstream/Filament territory, not this.
• You want current-generation Pest output. The --pest flag is a 2020-era Pest 0.x stub; expect to rewrite the generated test to Pest 2/3 idioms either way.

Migration cost if abandoned: low. Because output is plain Laravel code, removal is "delete the dev dependency." That asymmetry — cheap to try, cheap to drop — is the single strongest argument for a time-boxed spike.

How to Pitch It (Stakeholders)

To executives (one paragraph): Craftsman is a free, MIT-licensed Laravel code generator that turns one command into a complete, working slice of an application — database table, model, controller, validation, and tests — rather than a day of copy-paste. It is a developer-productivity tool, not a product feature: it ships nothing to customers and adds no runtime or security risk. The catch is unchanged: the project's latest release is 1.10.1, dated 3 July 2020 — a small patch adding a Pest test option and fixing a generated migration/model naming bug — and it has no downstream dependents, so it is unmaintained. That the most recent act of maintenance was correcting a wrong property name in generated code is itself the argument for treating output, not the tool, as the thing to review. Recommendation: fund a one-day, time-boxed spike on a throwaway branch. If it works on our stack, we get a measurable reduction in boilerplate time on CRUD-heavy work. If it does not, we lose a day and keep the design ideas. Either way, do not put it on the critical path.

To engineering (the honest version): This is a stub-and-convention engine with a craft: command namespace that emits models, controllers, migrations, seeders, factories, requests, resources, tests, and views, with flags to generate the whole set at once against a configured path/namespace layout. The value is entirely in the convention, and the convention is five years old. 1.10.1 changes little strategically: craft:test --pest (plus --unit) lets you emit Pest-formatted test stubs, and craft:migration --tablename now produces a CreateXXXTable class name and a protected $table = "..." property instead of the previously wrong $tablename. The second item matters more than the first — it means prior versions generated subtly invalid model code, so read every generated diff. Two viable plays: (1) Spike — install on a branch, generate one representative resource, diff the output against our current make: output, and judge on the diff, not the docs. (2) Reimplement — if the diff looks good, port the conventions we like into published stubs or a ~200-line internal artisan command (Pest flag included). Given zero dependents and a 2020 release, play (2) is the more likely long-term answer; play (1) tells us whether it is worth the two days. Do not add it to composer.json as a shared team dependency without a named owner.