Core Recommended Laravel Package

Product Decisions This Supports

• CMS/platform selection (build vs. buy). Choosing Drupal as the content platform is the real decision here; drupal/core-recommended is the default dependency-management layer that ships with every drupal/recommended-project install. Adopting it signals "standard Drupal, standard toolchain," which matters when weighing Drupal against a custom Laravel build or a SaaS CMS.
• Stability vs. flexibility for a long-lived product. The package pins Drupal core's transitive dependencies (Symfony components, Guzzle, Twig, etc.) to the exact versions core was tested against. This is a deliberate product trade: fewer surprise regressions in exchange for less freedom to cherry-pick upstream library updates. Decide this once, document it, and it becomes a standing engineering policy rather than a per-sprint debate.
• Security patch cadence and regression risk. Pinned, tested dependency sets shorten the "did the last Composer update break the site?" loop. Relevant to SLAs, incident budgets, and how confidently you can promise a patch turnaround to customers or compliance reviewers.
• Roadmap and major-version planning. Drupal 10 → 11 (and future majors) migrations are materially easier when the dependency graph is the known-good one. This package is a lever for planning upgrade windows and estimating migration effort.
• Portfolio / fleet consistency. If you run multiple Drupal sites or a multi-tenant product, standardizing on core-recommended gives you one dependency baseline to test, patch, and audit across the estate.
• Contributed-module and custom-code strategy. The pin can conflict with contributed or custom modules that require newer Symfony/Guzzle versions. That's a product-visible constraint: it shapes which modules you can adopt and how much you invest in a "break-glass" process (removing the metapackage and managing dependencies yourself).
• Reproducibility and audit posture. A lockfile-driven metapackage supports reproducible builds and makes dependency provenance easier to explain to security/compliance stakeholders.

Note for framing: this is a Drupal package, not a Laravel one. It belongs to the Composer/PHP ecosystem, but its value is entirely Drupal-specific. If the product is Laravel-based, this package is out of scope — the analogous decision there is your own composer.lock and dependency-update policy.

When to Consider This Package

Adopt it when:

• You are building or maintaining a Drupal 8.8+/9/10/11 site managed with Composer — it is the default and the path of least resistance.
• You want out-of-the-box, tested dependency versions and are not planning to aggressively manage Symfony/Guzzle/Psr transitive versions yourself.
• Your team is small or does not have a dedicated platform/dependency owner, so inheriting Drupal's tested combination is cheaper than curating your own.
• You value predictable, reproducible installs across environments and multiple sites.
• You are on a managed host (Acquia, Pantheon, Platform.sh) — check their guidance first, but most align with the recommended project structure.

Look elsewhere (or plan to remove it) when:

• The product is not Drupal — Laravel, Symfony standalone, or any non-Drupal PHP application. This package has no role there.
• You need to track upstream library releases closely (e.g., a security fix in a Symfony component that core hasn't yet pinned). You can remove the metapackage and manage dependencies directly, but that's a deliberate, ongoing commitment.
• Your contributed/custom module set requires versions the pin forbids — expect Composer conflicts and a decision about which constraint to relax.
• You are running a Drupal distribution that already pins its own dependency set; layering this on top creates redundant or conflicting constraints.
• You want bleeding-edge Drupal (dev branches, release candidates) — the metapackage is designed around tagged, tested releases.

Also worth flagging internally: low GitHub stars (~69) are misleading here. This is a drupal.org-maintained metapackage distributed via Packagist and pulled in by the standard project template; its real adoption is effectively every modern Composer-managed Drupal site. Do not let star count drive the decision.

How to Pitch It (Stakeholders)

For executives: This is a free, community-maintained component that comes standard with modern Drupal. It locks our CMS to a set of dependency versions the Drupal project has already tested together, which reduces the chance that a routine library update takes the site down. The trade-off is deliberate: slightly less freedom to chase individual library updates in exchange for fewer production surprises and a cleaner, more predictable upgrade path. There is no licensing cost and no vendor lock-in — we can remove it if it ever constrains us.

For engineering: drupal/core-recommended pins core and its transitive dependencies to core's tested versions. It is included by default in drupal/recommended-project and is the supported baseline. Practical implications: dependency upgrades happen on Drupal's cadence rather than ours; Composer conflicts with contributed modules are more likely and should be triaged early; removing the metapackage is supported but transfers dependency management to us. Recommend we standardize on it unless a specific module forces otherwise, and document the exception process.

For product/roadmap: Treat it as an infrastructure default, not a feature. The decisions it influences are upgrade timing (Drupal major versions), acceptable dependency-update latency, and which contributed modules we can adopt without friction. It does not differentiate the product; it reduces the operational risk behind it.