Core Recommended Laravel Package

Technical Evaluation

Architecture fit

drupal/core-recommended is not a Laravel package — it is a Composer metapackage published by the Drupal project that installs drupal/core plus a curated set of Symfony components and third-party libraries, all pinned to the exact versions resolved in the Drupal release lockfile. It ships no application code, no service provider, no facade, and no config. It is a dependency-constraint artifact whose only job is to keep a Drupal site on a tested combination of transitive dependencies.

For a Laravel codebase, that means there is no in-process integration story. Installing it would attempt to pull drupal/core (a full CMS application with its own front controller, routing, entity system, and database schema) alongside Laravel's own symfony/* constraints. Laravel 10/11 pin symfony/* to the 6.x/7.x lines with their own patch floors; Drupal 10/11 pin the same components to different exact versions. Composer will either refuse to resolve or, worse, resolve to a combination neither project tests. drupal/core-recommended also replaces drupal/core, so any attempt to co-install or selectively override is explicitly unsupported by the maintainers.

The honest architectural read: this is a "choose one application framework per runtime" situation. The package is relevant to a Laravel/PHP team only if Drupal is being introduced as a separate service, not as a library.

Integration feasibility

• Co-installation in one Composer project: effectively infeasible. Expect hard conflicts on symfony/console, symfony/http-kernel, symfony/routing, psr/*, and twig/twig. Even a successful resolve would produce an untested, unpatchable dependency graph.
• Side-by-side deployment: feasible and standard. Drupal in its own container/vhost with its own composer.json, exposed over JSON:API, GraphQL, or a custom REST module; Laravel consumes it as an HTTP dependency.
• Headless Drupal: feasible. drupal/core-recommended plus a minimal profile, JSON:API in core since Drupal 8, OAuth2 via simple_oauth. Laravel becomes the delivery/presentation layer.
• Reverse direction (Laravel as the content backend, Drupal as the edge): not viable — Drupal expects to own its request lifecycle and database.

Technical risk

• Version-lock coupling. The metapackage pins patch versions of ~30 Symfony and third-party libraries. You cannot independently patch a vulnerable transitive dependency without abandoning the metapackage — at which point you own the compatibility matrix yourself.
• Security cadence dependency. Drupal ships security releases on a predictable but frequent schedule (PSAs, often monthly, sometimes out-of-band for criticals). Consuming this package means tracking that cadence or accumulating known-CVE exposure.
• Upgrade blast radius. Moving Drupal 10 → 11 is a major-version migration (PHP 8.3 floor, Symfony 7, removal of deprecated APIs). If Laravel is coupled to the same PHP runtime image, that upgrade gates the Laravel upgrade path too.
• Low signal on the provided metrics. 69 stars and an "unknown" repository reflect that this is a metapackage distributed via Packagist/drupal.org, not a community library. Star count is not a health indicator here; the real health indicator is Drupal core's release and security coverage, which is strong but has nothing to do with this repo's popularity.
• Attribution / supply chain. Pulling a metapackage that fans out to dozens of transitive dependencies widens the SBOM considerably. Verify provenance and pin via composer.lock + composer audit in CI.

Key questions for the requester

1. What is the actual objective — content authoring, editorial workflow, taxonomy, or "we inherited a Drupal site"? The answer completely changes the recommendation.
2. Is there an existing Drupal estate, or is this a greenfield consideration? If greenfield, why Drupal rather than a Laravel-native CMS (Statamic, Filament, Winter)?
3. Does the team have Drupal skills today, or would this be a first exposure?
4. Is the constraint "must run on the same PHP-FPM pool / same repository" or "must be reachable by the same product"? Only the former is a blocker.
5. Who owns Drupal security patching on an ongoing basis, and what is the SLA for applying core SA releases?
6. What is the target PHP version across the estate, and does it satisfy both frameworks' floors simultaneously?

Integration Approach

Stack fit

Treat Drupal as a bounded context service, not a dependency. The correct topology is:

• Laravel application — owns the product domain, auth for end users, business logic, queues, and the public API surface.
• Drupal service — owns content types, editorial workflow, media, revisions, and multilingual content. Runs in its own container with its own composer.json, composer.lock, PHP-FPM pool, and database.
• Contract between them — JSON:API (in core) for reads, a thin custom module or GraphQL for writes/computed fields, OAuth2 client-credentials for machine auth.

If the requirement is genuinely "one codebase," the correct recommendation is to not adopt this package and instead evaluate a Laravel-native content solution. Say so explicitly rather than attempting a co-install.

Migration path

Scenario A — introducing Drupal alongside Laravel (greenfield):

1. Stand up Drupal in an isolated container in the existing orchestration (Docker Compose locally, ECS/K8s in staging).
2. Install drupal/core-recommended + drupal/core-dev in that container's own Composer project. Do not merge into the Laravel composer.json.
3. Enable JSON:API, configure content model, roles, and OAuth2 consumers.
4. Build a Laravel-side client (HTTP client + DTOs + caching) behind an interface so the content source can be swapped.
5. Add contract tests against the JSON:API schema in Laravel's CI.

Scenario B — migrating off Drupal to Laravel:

1. Inventory content types and fields via JSON:API /jsonapi index.
2. Export content to an intermediate format; import into Laravel models via queued jobs.
3. Run both systems read-only in parallel; shadow-compare rendered output.
4. Cut over DNS/route by route. Do not attempt to run both in one PHP process during the transition.

Compatibility

• PHP floor: Drupal 10 requires PHP 8.1+; Drupal 11 requires 8.3+. Laravel 10 requires 8.1+, Laravel 11 requires 8.2+. The intersection is workable if and only if the services run on separate images — then each can track its own floor and the shared constraint is only the base OS image.
• Symfony components: the hard incompatibility. Isolate by process boundary; never by Composer constraint gymnastics.
• Database: plan for a second database (MySQL 8 or Postgres 15+). Do not attempt shared-schema or cross-database joins.
• Cache/session: separate Redis logical databases or separate instances. Never share a cache prefix between Laravel and Drupal.

Sequencing

1. Discovery (1 week) — answer the six questions above; confirm the objective is content, not "install this package."
2. Decision gate — separate service vs. abandon. Do not proceed to build without an explicit decision.
3. Spike (1–2 sprints) — side-by-side containers, one content type end-to-end through JSON:API into a Laravel Blade/Inertia view, including cache and auth.
4. Contract definition — OpenAPI/JSON:API schema snapshot, versioning policy, error semantics.
5. CI/CD — two independent pipelines, two lockfiles, composer audit in both, Drupal security advisory monitoring wired to on-call.
6. Incremental delivery — migrate content type by content type; keep the Laravel-side client behind a feature flag.

Operational Impact

Maintenance

Two release trains instead of one. Drupal core security releases land roughly monthly plus out-of-band criticals; each requires a composer update drupal/core-recommended --with-dependencies, a config export/import (drush cex/cim), and a regression pass. Laravel ships minor releases every six months and patches weekly. Budget roughly 0.2–0.3 FTE for Drupal upkeep alone on a small site, before content operations.

The metapackage's pinning cuts both ways: it makes upgrades deterministic and well-tested by the Drupal community, but it removes your ability to hot-patch a single transitive dependency. Accept that trade-off consciously.

Support

Internal Laravel talent will not transfer — Drupal's entity/field/plugin architecture, Twig theming, and config management system are a distinct skill set. External support is available (Acquia, Pantheon, Phase2, the Drupal Association), but it is a separate vendor relationship and a separate budget line. There is no "Laravel maintainer also covers Drupal" story.

Scaling

Drupal does not scale the same way a stateless Laravel API does. Expect to need:

• Redis for cache, lock, and flood tables (Drupal's database-backed defaults collapse under load).
• Varnish or Fastly in front, with Drupal's cache-tag invalidation wired up — otherwise editorial saves will not purge correctly.
• A separate read replica if JSON:API traffic is significant; JSON:API is expensive without jsonapi_extras and sparse fieldsets tuned.
• BigPipe / dynamic page cache tuning if any Drupal-rendered pages remain.

Each of these is an additional operational surface the Laravel side does not currently carry.

Failure modes

Ramp-up

For a team that is strong in Laravel and new to Drupal: 6–10 weeks before a developer is independently productive in Drupal (module development, config management, Twig, Drush workflows). Theming and editorial UX add more. Estimate 2–3 sprints just to reach a credible spike, and treat the first production content type as a learning exercise with generous padding.

The recommendation to leadership is unambiguous: do not install this package into a Laravel application. Either adopt Drupal as a deliberately separate, separately-owned service with its own on-call and patch cadence, or do not adopt it at all. The cost is not the integration — the integration is straightforward HTTP — the cost is the second platform your team now operates.