Drupal Finder Laravel Package

Product Decisions This Supports

• Build vs. buy (build vs. reuse): Answers "should we write our own Drupal root detection?" with a clear no. Finding the Drupal docroot across Composer layouts (web/, docroot/, project root), Drupal 7 vs. 8+ structures, multisite installs, and symlinked vendor paths is deceptively fiddly. drupal-finder already encodes those heuristics and is pulled in transitively by tooling like Drush and PHPStan Drupal extensions.
• Developer tooling & platform roadmap: Unlocks or de-risks features that need to know where Drupal lives before they can act — custom Drush commands, CI/CD scripts, deployment automation, static analysis, config audits, scaffolding tools, and health-check commands.
• Internal platform/DX investment: If we ship a Drupal-based product or distribution, this is a low-cost dependency that makes our tooling layout-agnostic and portable across customer project structures.
• Use-case fit: Best suited to CLI/dev-time tooling and automation, not to runtime request handling (the HTTP layer already knows its own paths).
• Licensing decision input: GPL-2.0 is a real product/legal gate — fine for open-source Drupal work, but it needs a legal review before it ships inside a proprietary or closed-source distribution.
• Opportunity signal: A high opportunity score against modest adoption (126 stars) typically means the package is under-recognized because it's consumed transitively rather than starred — leverage is high relative to visibility.

When to Consider This Package

• You are building Drupal-adjacent tooling (CLI commands, CI checks, deploy scripts, code generators) and need a reliable way to locate the Drupal root or confirm "is this a Drupal project?"
• Your tooling must work across multiple project layouts — Composer drupal/recommended-project, custom docroots, legacy Drupal 7 trees, multisite — rather than a single repo you control.
• You want to avoid reinventing path heuristics and the maintenance burden of tracking Drupal layout changes.
• You are already in the Composer/Drupal ecosystem and want a small, focused, single-responsibility dependency.

Look elsewhere when:

• The product is not Drupal-based — this is purpose-built and irrelevant outside that ecosystem.
• You control the project layout end-to-end and a configured path or environment variable is sufficient; adding a dependency buys you nothing.
• You need more than root detection — bootstrapping, service container access, or runtime Drupal APIs — in which case use Drush or Drupal's own bootstrap instead.
• GPL-2.0 conflicts with your distribution model and legal sign-off isn't available; treat this as a blocking gate, not a footnote.
• You require an actively evolving, feature-rich library with a large, visible maintainer base — this is a small, stable utility and should be evaluated as such.

How to Pitch It (Stakeholders)

For executives: This is a small, free, open-source PHP utility that reliably answers one question — "where does Drupal live in this project?" Rather than paying engineers to build and maintain that logic ourselves, we adopt a proven component already used across the Drupal tooling ecosystem. It accelerates our developer-tooling roadmap at near-zero cost, but it carries a GPL-2.0 license, so we route it through legal review before embedding it in anything proprietary.

For engineering: webflo/drupal-finder gives us one API for root detection instead of brittle, hand-rolled path guessing. It handles Composer docroots, legacy layouts, multisite, and symlinks, and it's already a transitive dependency of mainstream Drupal tooling, so it's effectively de-risked. It's stable and recently released (June 2024) but intentionally narrow in scope — expect a small, single-purpose library, not a framework. Keep it confined to CLI/dev-time tooling, and confirm GPL-2.0 compatibility with legal before shipping it in a closed-source context.