Think Installer Laravel Package

Product Decisions This Supports

• Build vs. buy for our own packaging/install layer. This is prior art for the "how do we control where Composer puts framework files" problem (custom install paths, composer-plugin type, installer-paths conventions). If we ever ship a framework distribution or a skeleton project, this is a 30-minute read that saves a 2-week discovery cycle — not a dependency to adopt.
• Framework distribution strategy. It encodes ThinkPHP 5-era decisions about split-package distribution (topthink/framework, topthink/think-* extensions) versus a single skeleton app. Relevant only if we are choosing between monorepo-skeleton, split packages, or PSR-4 auto-discovery for a PHP framework product.
• Legacy modernization / migration sequencing. For any ThinkPHP 5.x property in the portfolio, this package is a migration blocker check: does removing it break composer install in CI? Answer determines whether a framework upgrade is a one-sprint or multi-sprint line item.
• Platform engineering guardrails. Composer plugins execute arbitrary code at install time and must be explicitly allow-listed (allow-plugins) under Composer 2.2+. This is a concrete input to our plugin allow-list policy and to whether third-party installers get approved in CI images at all.
• Catalog/data hygiene. Flagged as a "Laravel/PHP package," it is in fact a ThinkPHP Composer installer plugin. Any scoring, recommendation, or roadmap signal derived from the "Laravel" tag here is invalid; fix the taxonomy and stop routing it into Laravel build-vs-buy comparisons.
• Explicitly not supported: roadmap prioritization, feature discovery, or user-facing capability decisions. There is no feature surface here.

When to Consider This Package

Consider it only when:

• You are maintaining a ThinkPHP 5.x application whose composer.json already pins this package, and you need to reproduce or debug its vendor directory layout exactly during a freeze-and-migrate window.
• You are writing your own Composer installer plugin and want a minimal reference implementation of InstallerInterface / LibraryInstaller path resolution.
• You need to audit or remediate plugin-based install hooks in an existing codebase before a Composer 2 upgrade.

Look elsewhere when:

• The project is Laravel — Laravel does not use a custom installer; composer create-project laravel/laravel plus standard PSR-4 autoloading covers it. This package adds nothing and is the wrong tool.
• The project is ThinkPHP 6/8 — modern versions rely on PSR-4 and standard Composer behavior; a custom installer is redundant legacy surface.
• You are starting any new project. Last release 2021-03-25, 13 stars, 0 dependents, no security-patching posture. Adopting it means owning it.
• You need path conventions for non-framework packages (assets, modules, themes) — use composer/installers, which is maintained, widely depended upon, and already in most vendor trees.
• Your org requires active maintenance, CVE response, or a named owner for every install-time code path.

Net: treat this as reference material, not a dependency. The only defensible adoption criterion is "already present in a frozen legacy codebase."

How to Pitch It (Stakeholders)

For executives — one line: This is a small, abandoned 2021 packaging utility for the ThinkPHP framework (not Laravel), with no meaningful adoption; we should not depend on it, and it does not merit roadmap capacity.

What it is: A Composer plugin that tells the package manager where to install ThinkPHP framework files. It is plumbing for someone else's framework distribution — roughly 100 lines of glue — not a product capability. The "Laravel" label in our catalog is incorrect and inflates its apparent relevance.

Why the low score is the right answer: 13 stars, 0 dependents, last release four years ago, no maintainer signal. Install-time plugins are exactly the category where staleness is a security concern rather than a cosmetic one — they run code during composer install, and the only thing standing between us and that code is a one-line allow-plugins entry.

Recommendation:

1. Reject as a dependency for all current and new work. Zero opportunity cost.
2. Allowlist it narrowly — only inside CI images that build legacy ThinkPHP 5.x apps, never globally.
3. If we build our own installer layer, start from composer/installers. Cheaper, maintained, already approved.
4. Correct the catalog tag from Laravel → ThinkPHP so it stops appearing in Laravel evaluations; the misclassification is the most actionable finding here.
5. Allocate zero roadmap capacity. The only calendar item is a scoped question for platform engineering: "which legacy ThinkPHP 5.x services still require this, and what is the upgrade path off it?"

Ask of engineering: a half-day inventory of repos that reference topthink/think-installer, with a go/no-go on removing it during the next maintenance window. That converts an unowned legacy risk into a scheduled, bounded task.