- What is ajthinking/archetype actually used for in Laravel projects?
- It is a dev-time AST-level PHP code manipulation library built on nikic/php-parser, not a built-in Laravel scaffolding framework. Use it for scripted, repeatable source edits such as creating classes, inserting methods/properties/constants, querying nodes, and applying codemods across many Laravel repositories. It is best suited to internal tooling, CI codemods, and generator pipelines, not product features or runtime code. Some descriptions of it as a visual Eloquent model designer do not match the actual changelog; validate against source.
- How do I install ajthinking/archetype, and should it be require-dev?
- It is Composer-installable, MIT licensed, and has no significant transitive baggage beyond php-parser. Because it writes PHP source files and has a contained blast radius, it belongs in require-dev rather than production dependencies. A time-boxed spike using PHPFile, astQuery(), insertStmt(), preview(), and commit() is cheap, but budget for the diff-review and test harness around it. In v1.1.0 PHPFile::make() moved to a Maker object, so check the version-specific API.
- Can Archetype generate Eloquent models, migrations, factories, and controllers?
- Not through a visual schema GUI as some blurbs suggest; the actual package is an AST editing library. You can script creation of PHP files and insertion of class, method, property, and constant nodes, so it can support generator pipelines that stamp Laravel artifacts. The package does not provide Eloquent-aware schema modeling or migration semantics out of the box. Treat vendor/marketing descriptions as unreliable and validate capabilities against source.
- Does Archetype work with Laravel service providers, config files, and migrations?
- Yes, in the sense that it edits PHP files and has no opinion about Laravel specifically. That means it can rewrite service providers, config files, migrations, and other PHP source consistently. The flip side is that it has no framework awareness, so your scripts must encode Laravel-specific rules and safety checks. Keep every automated write behind review and static analysis.
- Which PHP and Laravel versions does Archetype support?
- The package fits PHP 8.x Laravel stacks as a dev-time tool, and v2.0.0 moves from php-parser 4 to php-parser 5. Laravel version support is not the main constraint because Archetype does not deeply integrate with the framework; the real constraint is which PHP syntax the pinned parser version supports. Validate enums, readonly, first-class callables, property hooks, and asymmetric visibility against your fleet's newest code before standardizing scripts.
- How do preview() and commit() work, and how do I avoid unsafe automated writes?
- The small API exposes preview() and commit() so you can inspect intended changes before writing source files. Note that v1.1.0 moved PHPFile::make() to a Maker object and removed __call magic, so use version-appropriate examples. Avoid unsafe writes by running on a branch, requiring human diff review, and gating with syntax checks, static analysis, and tests. Also test that preview()/commit() round-trip untouched files byte-identically.
- Does Archetype preserve PHP formatting and produce clean, reviewable diffs?
- Format-preserving printing is the known weak spot; the maintainer flags persistent formatting bugs and incomplete tests around pretty-printing. For a codemod tool, cosmetic churn is not cosmetic because it destroys diff reviewability and can cause reviewers to approve blindly. Measure diff-noise rate on a representative sample of your repositories. If reviewers cannot see a clean, minimal diff, do not trust the automation yet.
- Is Archetype safe to use in production or at runtime?
- No, it should never sit on a production request path because its job is to write PHP source files. Keep it in require-dev, run it only in controlled tooling or CI, and contain the blast radius with branches and human review. The real cost is the harness around it: diff review, syntax and static-analysis gates, and a test run before any automated write is trusted.
- How should I test Archetype codemods and handle rollback?
- Start with one concrete codemod and test it against representative repositories, including files you do not intend to change. Require byte-identical round trips, clean diffs, passing syntax checks, static analysis, and the full test suite before accepting writes. Always run on a branch with mandatory human diff review, and keep a straightforward rollback path such as reverting the branch or discarding the patch. Assign an owner for the internal wrapper and the php-parser upgrade cadence.
- What are alternatives to Archetype, and how risky is its maintenance?
- Rector overlaps heavily with Archetype for codemods and has far deeper adoption, while using nikic/php-parser directly or Laravel Pint-style tooling may cover narrower needs. Archetype's risk is structural: it is single-maintainer, low-adoption with about 271 stars and zero dependents, tightly coupled to a php-parser major, and has a history of API churn. v1.0.0 removed Schema, Project, Generators, and the Trait endpoint, and v1.1.0 changed PHPFile::make(); documentation is also acknowledged as incomplete. Decide explicitly whether the internal wrapper and parser upgrades are a platform-team line item or an orphan script.