Core Project Message Laravel Package

Product Decisions This Supports

• Developer onboarding / time-to-first-value. The package's entire job is to print a message after composer install / create-project completes. That makes it a lever on developer onboarding, not end-user experience: every new engineer who runs the template gets the "here's what to do next" guidance automatically, instead of relying on a wiki page that decays.
• Distribution and starter-kit strategy. If we ship an internal Drupal template, agency starter kit, or a distribution, this is the cheapest possible place to put next-step instructions, support channel links, and environment setup reminders — versioned in the same repo as the code, so it can't drift out of sync the way a Confluence page does.
• Build vs. buy vs. configure. This is a configure, not a build. It ships inside drupal/core, so the decision is not "adopt a dependency" but "do we spend an hour customizing a message we already have?" There is no meaningful build alternative — writing our own Composer plugin for this would be pure waste.
• Support-cost reduction. Each onboarding question answered by the post-install message is a ticket not filed. Worth tracking: onboarding ticket volume, time from git clone to first successful local site boot, and the percentage of our project templates with a customized message.
• Roadmap framing. Treat as config-level polish (hours, not sprints), grouped with DX/DevEx work. It should never occupy roadmap space ahead of anything that affects customers, performance, security, or upgrade cost.
• What it explicitly does not decide: it is not a runtime dependency, has no bearing on production behavior, security posture, or performance, and gives us no vendor leverage. Low star count (21) is a subpackage artifact, not a quality signal — it rides Drupal core's maintenance.

When to Consider This Package

Consider it when:

• We are on Drupal (8/9/10/11) and starting from drupal/recommended-project or a distribution — the plugin is already in the dependency tree, so the only work is customizing the message text in the project's composer.json extra configuration.
• Our developers are new to Drupal, or the template has non-obvious post-install steps (database, Solr, config import, Drush commands) that are currently tribal knowledge.
• We want zero-maintenance DX polish: no service to operate, no version to pin independently, no runtime footprint.
• We need a static, deterministic notice. It is a megaphone, not a setup wizard.

Look elsewhere when:

• The stack is not Drupal. For Laravel this package is the wrong tool — the equivalent is a Composer post-create-project-cmd script or the installer's own console output. The pattern transfers; the package does not.
• We need anything interactive or conditional: environment validation, prompts, scaffolding, generating .env, seeding data, checking PHP extensions. That's Composer scripts, drupal-scaffold, or a custom installer plugin — a bigger, separate decision.
• We are not already on Drupal's core package set. Pulling in a standalone Composer plugin solely to print a string is over-engineering; a post-install-cmd echo does the same job with one less dependency.
• GPL-2.0 is a blocker for legal. Unlikely here — it's build-time tooling that never ships to customers — but confirm with counsel rather than assuming, especially if we redistribute a packaged product.
• We need an SLA or independent release cadence. There is none; it moves when Drupal core moves, and it follows core's security policy.

How to Pitch It (Stakeholders)

To executives (30 seconds): This is a free, near-zero-risk utility that ships inside Drupal core and prints guidance to developers the moment they install our project. It converts onboarding knowledge that currently lives in someone's head into an automatic, version-controlled message. Cost is measured in hours; the return is fewer support tickets and faster ramp-up for new engineers. Nothing about it touches production or customers.

To engineering: It's a Composer plugin with no runtime footprint — build-time only, never loaded by the application. Configuration is a message string in composer.json; it can be disabled by dropping the plugin, so the decision is fully reversible. Licensing is GPL-2.0, which is fine for build tooling but should be a one-line check with legal before we redistribute a packaged artifact. It has no independent release cadence or support commitment — it inherits Drupal core's.

The honest caveat: this is DX garnish, not strategy. It improves how our own developers experience the template and reduces a class of avoidable tickets, but it should be approved in minutes and never argued about for a sprint. If it takes more than an afternoon, we've mispriced it.