Core Project Message Laravel Package

Technical Evaluation

Architecture fit. The first thing a TPM needs to flag is a categorisation mismatch: despite being routed as a "Laravel/PHP package," drupal/core-project-message has nothing to do with Laravel. It is a Composer plugin — a small event subscriber that hooks post-create-project-cmd / post-install-cmd and prints a configured message to the terminal. Its only consumer is a Composer project template (the Drupal recommended-project / drupal-project skeletons), not an application runtime. For a Laravel codebase there is no architectural slot for this package: Laravel applications are not distributed as Composer project templates, and Laravel's own post-create-project-cmd script already covers the "print next steps after install" use case. Architecture fit for a Laravel shop is therefore effectively nil.

Integration feasibility. Mechanically trivial. It is a require-dev-grade, build-time-only dependency added to a composer.json, requiring a Composer 2.2+ config.allow-plugins entry (drupal/core-project-message: true) and a message payload in extra. There is no service provider, no config publishing, no DB, no HTTP surface, no autoloaded runtime code. If the goal were genuinely "emit a post-install banner from our internal Composer skeleton," it could be wired in under an hour. The real question is whether that goal exists.

Technical risk. Low-to-moderate, and almost entirely non-technical:

• Supply chain / execution: Composer plugins execute arbitrary code during install/update. That is a privileged position for a 21-star package, even one published under the drupal vendor namespace. allow-plugins is a deliberate guardrail — allow-listing it for a Laravel project widens the trusted-plugin set for zero functional gain.
• Licensing: GPL-2.0. As build tooling that never ships in a distributed artifact this is normally defensible, but it is a legal-review item in any org with a strict OSS policy, and it is inconsistent with the MIT/Apache posture typical of Laravel stacks.
• Viability signal: score 0.195 and 21 stars look alarming in isolation, but this is a drupal/core-* component — its real maintenance home is the Drupal core release cycle, not GitHub popularity. Treat the metrics as not meaningful rather than bad, and verify the Drupal core dependency instead.
• Redundancy: Composer scripts (post-create-project-cmd) achieve the same output with no plugin and no allow-list change. The plugin's marginal value over a shell echo is close to zero outside Drupal's specific template conventions.

Key questions for the evaluation owner.

1. What is the actual use case — are we building an internal Composer project template, or did this get pulled in transitively by a Drupal-adjacent dependency?
2. Is it in the dependency graph as a direct requirement or as a transitive consequence of drupal/core-recommended? If transitive, the decision is "tolerate" not "adopt."
3. Which Drupal core minor is it pinned to, and is the component still carried forward in the core versions we track?
4. Does Legal accept GPL-2.0 build tooling in this repository?
5. Could a plain Composer script satisfy the requirement, removing the plugin and the allow-list exception entirely?

Integration Approach

Stack fit. Poor for Laravel, native for Drupal. A Laravel team's correct posture is do not add this to application repositories. The only defensible placement is inside a Composer project template (a skeleton repo) whose consumers are Drupal projects, or a template explicitly modelled on drupal/recommended-project. Anywhere else it is dead weight that still demands an allow-plugins exception.

Migration path. There is nothing to migrate — no existing behaviour is replaced. If the underlying need is "tell developers what to do after composer create-project," the migration is away from this package: implement a scripts.post-create-project-cmd entry in composer.json that prints the guidance. That path is framework-agnostic, requires no plugin allow-listing, no GPL review, and no third-party execution at install time. If a Drupal project is already using it, removal is a one-line composer remove plus deleting the extra message payload and the allow-plugins entry — a zero-risk rollback.

Compatibility. Constrained by Composer version, not PHP or Laravel version. Composer 2.2+ enforces allow-plugins; on Composer 1.x (EOL, but still present in some legacy images) plugin behaviour differs and the allow-list prompt does not exist. Confirm the Composer baseline of every CI runner and base Docker image before assuming it works identically across environments. Message output is plain terminal text — no compatibility surface with Laravel, PHP-FPM, or Octane.

Sequencing (if, and only if, a Drupal template is in scope).

1. Confirm the template is a Composer project skeleton, not an application.
2. Add the requirement at the version aligned with the Drupal core minor already pinned in that template.
3. Add the allow-plugins entry and the extra message payload in the same commit.
4. Validate with a clean composer create-project in a throwaway directory on both a developer workstation and the CI image.
5. Verify non-interactive CI output remains parseable — banner text in logs is a real friction point for log-based alerting.

For a Laravel template, sequence item 1 fails and the work stops there.

Operational Impact

Maintenance. Near-zero code maintenance, but non-zero governance maintenance: the version must track whatever Drupal core minor the surrounding template pins, and the allow-plugins exception must be re-justified at each dependency review. A no-dependency Composer script has strictly lower ongoing cost, which makes this package a net-negative maintenance trade for a team that gains nothing from it.

Support. No vendor support, no SLA. Upstream is the Drupal core issue queue — responsive by open-source standards, but we would be a non-target user (Laravel) with no leverage. Internal support burden is minimal because the failure surface is one terminal message. Realistically, if it breaks the fix is "delete it," which caps the blast radius.

Scaling. Irrelevant in the runtime sense — no request path, no memory, no I/O, no queue interaction. The only "scale" dimension is build-time: it runs once per composer install/create-project. On a large fleet that is a sub-second addition, but it also runs on every CI job that installs dependencies, meaning a plugin that throws will fail builds broadly rather than narrowly.

Failure modes.

• Blocked plugin: not present in allow-plugins → Composer skips it with a warning; message silently never prints. Benign but confusing ("why did our onboarding text disappear?").
• Allow-list prompt in CI: non-interactive environments can hard-fail or hang on the plugin-authorisation prompt if config is incomplete.
• Install-time exception: a malformed extra payload or an upstream bug throws during post-install-cmd, failing the whole dependency install — the highest-severity scenario, and one that a scripts echo avoids entirely.
• Log noise: banner text in CI output can trip naive log scanners and inflate log volume; low severity, occasionally annoying.
• Silent drift: if the package is ever dropped from the Drupal core monorepo, teams on a floating constraint get a resolution failure with no obvious cause.
• No security, data-integrity, or runtime failure modes exist.

Ramp-up. Minutes. A developer reads the README once, understands it is a banner printer, and moves on. The costly part is not learning the package — it is the process overhead of the GPL review, the plugin allow-list exception, and the recurring "why do we have this?" conversation at dependency-review time.

TPM recommendation. Do not adopt for Laravel work; reclassify this item out of the Laravel/PHP backlog. If it arrived transitively via a Drupal dependency, mark it as tolerated-transitive and move on. If the team genuinely needs post-install developer messaging in a Composer template, implement it with a post-create-project-cmd script — same outcome, no plugin execution, no GPL question, no allow-list exception, and a smaller operational footprint than the package under review.