Core Composer Scaffold Laravel Package

Product Decisions This Supports

• Build vs. buy for project scaffolding. This package is the reference implementation of the "Composer plugin that copies opinionated skeleton files into your project, then keeps them updatable" pattern. It directly informs the decision of whether to hand-roll a starter-kit/installer for a Laravel SaaS template, an internal platform template, or a multi-tenant deploy layout — versus using composer create-project, laravel new, or an existing starter kit.
• Starter-kit / boilerplate roadmap. If we ship a productized Laravel skeleton (index.php overrides, .htaccess/web-server config, robots.txt, env templates, CI stubs), the question "how do customers receive upstream changes to those files without losing local edits?" is exactly what this plugin solves via scaffold:update semantics, append/prepend rules, and managed .gitignore entries. That is a real roadmap decision, not a hypothetical.
• Upgrade-path design. It demonstrates a governance model for files that must live in VCS and be refreshed on dependency updates — relevant if we're weighing "pin the template once" vs. "keep the template syncable" for customer deployments.
• Platform/DevEx investment sizing. Reviewing it gives a cost estimate for building equivalent behavior in-house (Composer plugin lifecycle hooks, allow-plugins policy, idempotency, conflict handling). Useful input to a build-vs-borrow spike before committing engineering time.
• Explicit non-decision: it supports no runtime, feature, or user-facing roadmap items. It has zero bearing on Laravel application behavior — this is tooling and supply-chain ergonomics only.

When to Consider This Package

• Only if Drupal is in scope. The plugin's default scaffold set assumes Drupal's project layout (web/ docroot, Drupal index.php, .htaccess, robots.txt, settings.php handling). Adopting it for a Laravel app means stripping the defaults and re-authoring the config — at which point you are maintaining a fork of a narrow tool.
• Consider the pattern, not the package, when: you maintain a distributable skeleton consumed by many downstream repos; downstream teams need to receive updated scaffold files without merge pain; you want file-level rules (replace / append / prepend / skip-if-modified) rather than a one-shot copy.
• Look elsewhere when:
  • You're building Laravel. Use laravel/installer + a private starter kit repo, or composer create-project, or the framework's publishing conventions (php artisan vendor:publish) if the files come from a package.
  • You need cross-framework scaffolding — generic tooling (cookiecutter-style generators, custom post-create-project-cmd scripts) is a better fit than something Drupal-shaped.
  • Composer plugin governance is a blocker. This requires allow-plugins approval under Composer 2.2+, which adds friction to CI, security review, and developer onboarding for every new machine.
  • Licensing is a constraint. GPL-2.0 is fine as a build-time CLI tool in most interpretations, but any proprietary distribution that vendors this code needs legal sign-off. Cheap to avoid; not worth the review cycle for a non-fit.
  • Maintenance signal matters. The metadata here is weak (unknown repository, 54 stars). Note the caveat: this is a split repo of Drupal core, so stars wildly understate real adoption — but that also means it's not independently versioned or maintained in the way a standalone dependency is. Treat it as "part of Drupal," not as a library you can depend on and shape.
• Adoption bar: if someone proposes this, they should be able to answer "which Drupal project?" If they can't, the answer is no.

How to Pitch It (Stakeholders)

To executives: This is a small, mature piece of Drupal's build tooling, not a Laravel dependency. It solves a real problem — shipping a project skeleton that customers can keep updating — and it's a useful reference for how we might build our own starter-kit upgrade path. Recommendation: do not adopt; borrow the pattern. Cost of adoption is near zero but so is the value, and GPL-2.0 plus Composer plugin-approval friction creates avoidable legal and CI overhead. If we want a scaffoldable Laravel template, that's a 1–2 sprint spike on our own tooling, and this package is the best free design doc we'll get.

To engineering: It's a Composer plugin that runs on install/update, copying a configured set of files into the project (with replace/append/prepend rules and managed .gitignore entries), tracking a hash so it can warn on local modification. Relevant mechanics to steal: idempotent file placement, explicit conflict policy, and keeping scaffolded artifacts in VCS while staying refreshable. Relevant risks to note: plugins execute arbitrary code at install time (requires allow-plugins in Composer 2.2+), the defaults are Drupal-specific and must be rewritten for anything else, and upstream is a core split — not a versioned library. Verdict: read the config schema, don't add the dependency.