Craft6 Revamp Laravel Package

Technical Evaluation

Architecture fit. Despite being filed under the PHP/Laravel package bucket, craftcms/craft6-revamp is not a library you install as a dependency — it is a project scaffold consumed once via composer create-project, equivalent in role to laravel/laravel. The value proposition is conventional: a cleaner directory layout, refactored config/environment handling, modernized template and asset organization, and a Composer-first workflow. Architecturally it is a Yii2 application (Craft 6), not Laravel, so any team expecting Eloquent, Blade, service providers, or app(Foo::class) will spend their first sprint on translation. The mapping table in the supplied docs is accurate and should be treated as the onboarding contract: php artisan → php craft, Eloquent → Elements/Element Queries, Blade → Twig, service providers → plugins/modules, and — most importantly — config/project/*.yaml as the authoritative content-model state, which has no Laravel analogue and is the single largest mental shift.

Integration feasibility. High for greenfield Craft builds and for greenfield-adjacent rebuilds; moderate-to-low for "revamp an existing Craft installation," which the description explicitly names as the target. A scaffold ships opinions, and opinions collide with live content models. The realistic consumption path is to use it to seed a new codebase, then port sections, fields, and templates over deliberately — not to drop it on top of a running install. The Composer-first posture and project-config YAML make the port tractable and reviewable, which is the redeeming factor.

Technical risk.

• Adoption signal is thin. 5 stars is a negligible community footprint. Mitigant: it lives in the first-party craftcms organization, so the maintenance risk profile resembles an official starter kit rather than an abandoned indie package. Still, expect to be your own support tier; do not plan on Stack Overflow density.
• Release opacity. The 1.1.2 notes are a bare compare/1.1.1...1.1.2 link with no prose. Semver implies no breakage, but zero disclosed detail on a scaffold release is a real hazard — a patch that alters config/project/*.yaml silently reshapes your content model. Mandatory diff of config/, composer.json, CHANGELOG.md, and config/project/ between tags before merging.
• Release metadata anomaly. The last release is stamped 2026-08-17. Confirm with the maintainer that this is intentional and that there is no published/unpublished tag confusion before pinning it as a baseline.
• Project config drift. The number-one operational failure mode. CP edits and YAML diverging produces phantom field disappearances and unexplainable project-config/diff output. --force overwrites; take a mysqldump first, always.
• Environment-flag traps. allowAdminChanges => false correctly hardens staging/production but also disables config-writing php craft commands, producing confusing "changes not allowed" errors on developer machines. Keep it environment-driven, never hardcoded.
• Yii container seam. Any package or internal code assuming Laravel's container (app(), facades, with() on queries) will fight you. Budget real time here if porting Laravel code.
• Element query N+1. Worse than Eloquent's because there is no ergonomic safety net — forgetting .with(['author','heroImage','topics']) is invisible until profiled.

Key questions for the maintainer / internal stakeholders.

1. Is 1.1.2 shipped from this tag, and is the 2026-08-17 date authoritative?
2. Do you publish a versioning/support policy (Craft 6.x LTS window, PHP version matrix) for the scaffold?
3. Does 1.1.2 touch config/ or config/project/? Provide the tag diff.
4. What is the intended path for existing Craft installs — greenfield seed plus manual port, or in-place upgrade? The description implies the former; confirm.
5. Do you accept issues/PRs on the scaffold, or is it frozen-by-design?
6. Any opinion on module structure (modules/site/) vs. plugin extraction for shared business logic?

Integration Approach

Stack fit. This is a whole-application stack commitment: Craft 6 / PHP on Yii2, Twig, MySQL or Postgres, Composer-managed plugins, and a queue worker. It slots cleanly into a standard PHP container pipeline (Docker/Forge/Valet/Sail) and is CI-friendly because the content model is text. It does not slot into an existing Laravel monolith as a package — treat it as a separate service or a replacement application, not a dependency.

Migration path. Recommended sequence:

1. Spike, don't commit. composer create-project craftcms/craft6-revamp into a throwaway environment. Configure .env (APP_URL, DB_*, SECURITY_KEY), run php craft install, php craft serve. Read in this order: .env.example → config/general.php → config/project/ → modules/ → templates/.
2. Prove the loop. Create one section in the CP, export project config, commit the YAML, have a second developer pull and run php craft up. That round trip is the daily operating rhythm — validate it before anything else.
3. Content-model port. Reproduce sections, fields, and entry types as project config in the new repo. Do not copy the database. Port templates after the model is stable.
4. Business logic into a Module. php craft make module, register in config/app.php, move event listeners, console commands, and controllers there. Reserve plugins for genuinely reusable third-party capability.
5. API surface check before writing controllers. Evaluate Craft's built-in GraphQL and Element API for headless/JS consumers — they bring permission checks you would otherwise reimplement.
6. Queue everything slow. Image transforms, external API calls, mail. php craft queue/listen under Supervisor, exactly as queue:work would be.

Compatibility. Pin PHP to whatever Craft 6 requires and hold it in composer.json. Enforce plugin management through Composer, not the plugin store, because enable/disable state lives in project config and the two must stay synchronized for deploys to be reproducible. Verify devMode is off outside local — it leaks stack traces and disables caching.

Sequencing. Sprint 1: spike, environment matrix, CI skeleton, project-config round trip. Sprint 2: content-model port and template scaffolding. Sprint 3: module extraction, queue worker, deploy pipeline (composer install --no-dev --optimize-autoloader → php craft up --interactive=0 → php craft clear-caches all → supervised queue). Sprint 4: legacy cutover behind a proxy, with a rollback path that includes a database snapshot.

Operational Impact

Maintenance. Low ongoing code footprint — you inherit a scaffold and then own it outright. The maintenance load is Craft 6 upgrades plus the drift discipline. Assign explicit ownership of config/project/; unowned YAML is how drift happens. Establish a rule: no content-model changes in staging or production via the CP, ever.

Support. The community footprint (5 stars) means limited external answers and limited third-party tutorials specific to this scaffold. However, the underlying platform (Craft, Yii2, Twig) is well documented, so the practical support gap is narrow: you will find Craft answers, not scaffold answers. Budget for one internal Craft-fluent engineer as the escalation point. If the org has Laravel-only depth, plan a deliberate knowledge investment rather than assuming transfer.

Scaling. Standard Craft scaling applies: read replicas, Redis for cache/sessions, dedicated queue workers, CDN in front of assets, image transforms on the queue. The scaffold imposes no scaling constraint and no scaling advantage — it is neutral here. The two scaling-adjacent items that will bite are element-query N+1 (hoist queries out of {% for %} loops; use .with()) and forgetting that php craft clear-caches all does not purge storage/runtime/compiled-templates, which sometimes needs manual clearing after a template-path change.

Failure modes to monitor.

• Project config drift — symptoms: fields vanish from CP after a pull, or project-config/diff shows edits nobody made. Response: mysqldump, then project-config/apply --force, then root-cause the CP edit.
• Silent devMode in staging — makes every query look ~10× slow; verify before opening any performance ticket.
• Config-write lockout — confusing "changes not allowed" errors from allowAdminChanges => false on a developer machine.
• Stale compiled Twig after deploy — blank or outdated template output despite clean caches.
• Queue starvation — transforms and mail back up unnoticed; alert on queue depth, not just worker liveness.
• Scaffold patch overwrite — merging a scaffold release that rewrites config/project/ and quietly reshaping the content model. Gate every bump behind a tag diff.

Ramp-up. Realistically 1–2 weeks to productive for a strong PHP developer with Twig or Blade experience, and the first hour is almost entirely vocabulary translation. The genuinely new concepts are project config as source of truth, Elements/Element Queries in place of ORM models, and the Yii service container. The supplied translation table is the right onboarding artifact — put it in the repo README and pair it with the php craft up round-trip as the first hands-on exercise. Do not let anyone touch the content model until they have completed that round trip successfully.

Recommendation. Worth a time-boxed spike (1–2 weeks) as the baseline for a new Craft 6 build. Do not adopt as an in-place upgrade mechanism for a live installation. Gate adoption on answers to the versioning and tag-diff questions above, and treat every future release as "assume safe, verify before merging."