Builder Bundle Laravel Package

Technical Evaluation

Bottom line: this is not a Laravel package. akyos/builder-bundle is a Symfony bundle — it registers via config/bundles.php, extends the Symfony kernel, depends on akyos/core-bundle ^8.0, uses Twig for rendering, Doctrine for persistence, and Symfony's dependency-injection tag system (akyos_builder.block_type) for extension. None of those primitives exist in Laravel. There is no drop-in path into a Laravel application, so the realistic TPM leverage here is pattern reference, not code reuse — unless we have a Symfony service in the estate.

Architecture fit. Poor for a Laravel stack. The package's core value — a visual page builder with reusable components, overridable templates, translatable values, Twig front-end rendering — is delivered through Symfony-specific seams (bundles, compiled container, tagged services, config tree in config/packages/akyos_builder.yaml). Every one of those seams has to be re-created to work with Blade, Eloquent, and Laravel's container. What remains portable is the domain model: a page has ordered blocks; a block has a type, a template, and typed fields; fields are translatable; render is a template lookup over stored JSON.

Integration feasibility. Low as a dependency; moderate as a design reference.

• Direct install into Laravel: not feasible. The composer require instruction and AkyosBuilderBundle::class => ['all' => true] registration only make sense inside a Symfony kernel.
• Adapter layer: technically possible only by embedding a Symfony kernel in the Laravel app (or a Twig bridge + HttpFoundation shims), which imports the entire Symfony runtime as a second framework. That is a maintenance liability, not an integration.
• Sidecar service: run a standalone Symfony 8 app exposing the builder via HTTP/API and have Laravel consume rendered output or block JSON. Viable, but it doubles the runtime footprint and adds a network hop per render.

Technical risk. High, and mostly vendor-risk rather than code-risk.

• Zero social proof. 0 stars, 0 dependents. No third party has validated this in production that we can observe. There is no community to catch regressions before we do.
• Hard transitive coupling. Requires akyos/core-bundle ^8.0. We inherit that package's roadmap, its bugs, and its Symfony compatibility lag as well.
• Very narrow compatibility envelope. PHP >= 8.4 and Symfony ^8.0. That excludes most managed PHP platforms' defaults and most of our vendor ecosystem, and puts us on the newest possible major of both runtimes simultaneously.
• Regressions already observed. 8.0.2 exists solely to fix Request::get() removal in Symfony 8 — a break in the admin editing surface, i.e. the primary user-facing path. This is a "found it in the field" patch history, which predicts recurrence.
• Metadata inconsistency. The listed last release date (2026-09-14) is in the future. Either the metadata is unreliable or the registry feed cannot be trusted; verify provenance before any procurement decision.

Key questions for the vendor / before any spike.

1. Is there a Laravel port, or a framework-agnostic/headless mode with a documented HTTP contract?
2. What does akyos/core-bundle actually pull in at runtime, and is it separable?
3. What is the license, and is commercial support or an SLA available?
4. Is there a documented persistence contract — can block data live in our tables as JSON, or does the bundle own the schema?
5. Who maintains this, and what is the response time on security issues?
6. Is the admin editor's JavaScript documented and versioned, or is it coupled to the Twig surface?
7. Is 8.0.2 truly the minimum installable version on Symfony 8, and are there known-unfixed issues below it?

Integration Approach

Stack fit: negative. For a Laravel codebase, the honest sequencing is do not integrate — treat this as a reference implementation for a build-vs-buy decision.

Options, ranked.

1. Build the pattern natively in Laravel (recommended). Mirror the domain model: a block registry (config-driven, analogous to the tagged akyos_builder.block_type services), a blocks JSON column on a pages table, Blade partials per block type, and a translatable field wrapper over Laravel's localization. This is days-to-weeks of work, not months, and it keeps us on one framework with a team that can maintain it.
2. Evaluate a Laravel-native builder or headless CMS. Compare against option 1 on license, lock-in, and editor UX.
3. Sidecar Symfony service. Only defensible if a Symfony 8 service already exists in the estate with an owned runtime, deployment pipeline, and Symfony-fluent engineers. Then Laravel becomes a BFF/proxy and this bundle is consumed behind an API.
4. Direct integration into Laravel. Reject.

Migration path (if option 3 is ever chosen).

• Run a throwaway Symfony 8 + PHP 8.4 app first. Pin akyos/builder-bundle:^8.0.2 — 8.0.1 and below throw UndefinedMethodError on the admin editor under Symfony 8.
• Keep block payloads in our own JSON shape, written through an anti-corruption layer around PageBuilder/PageRenderer. Never let the bundle's entity schema become our system of record; that is what makes exit impossible.
• Gate acceptance on an admin smoke test: open a page, add a component, set a field, save, reload, assert the value persisted. That single test catches the exact class of bug 8.0.2 fixed.
• Audit any surrounding code for $request->get() before go-live; convert to query/request/attributes/getPayload() bags explicitly.

Compatibility constraints to record. PHP 8.4 floor; Symfony 8 floor; CoreBundle 8 floor; bundle 8.0.2 floor. Any infra that cannot run PHP 8.4 rules this out before evaluation.

Sequencing. (1) One-week timeboxed spike to confirm the framework mismatch and produce the native-Laravel effort estimate. (2) Parallel license/support/maintenance diligence. (3) Build-vs-buy decision inside one sprint. Do not start with the integration — start with the decision.

Operational Impact

Maintenance. If integrated, we become the maintainer of a two-package Symfony stack inside (or beside) a Laravel team's remit, on the newest PHP and Symfony majors simultaneously. Every Symfony minor becomes a project. The 8.0.2 patch is the template: an upstream major removal silently breaks the primary admin workflow, and we find out from a user.

Support. No evidence of an SLA, commercial support tier, or a maintainer team beyond a single vendor organization. Response time on issues is unknown. Budget an internal owner with Symfony fluency regardless — that person does not currently exist on a Laravel team and will need to be hired or contracted.

Scaling. Rendering is per-page Twig compilation with no documented caching beyond an optional cache flag in sample code. Block-heavy pages will be the cost center. If deployed as a sidecar, add an HTTP cache in front of the render endpoint or you pay a network hop plus a full render on every request.

Failure modes to instrument for.

• Silent field loss: request-bag misuse produces nulls that read as "the builder doesn't save my component" — log raw query/request/attributes bags, not the merged result.
• Block-type registry drift: config block name not matching a tagged service yields "Block type not found" at render time, not at config time.
• Template override path drift: overrides must match the exact templates/akyos_builder/blocks/... structure, which can move on upgrade.
• Circular block references and Doctrine lifecycle listener priority conflicts with our own subscribers.
• Upstream CoreBundle breakage on a Symfony patch, taking down the builder with no code change on our side.

Ramp-up. Realistically 2–4 weeks before a Laravel developer can make a safe change in a Symfony bundle codebase (bundles, compiled container, tagged services, Twig inheritance, Doctrine listeners). Documentation is French-language and thin, which adds friction for the broader team. Compare against a native Laravel implementation where the existing team is productive on day one.

Recommendation. Do not adopt as a dependency for a Laravel product. Extract the domain model as a reference and build the block registry natively, or select a Laravel-native alternative. Revisit only if a Symfony 8 service already exists and can own the runtime, at which point pin 8.0.2 minimum and gate the rollout on the admin-editor smoke test.