Composer Npm Bridge Laravel Package

Product Decisions This Supports

• Distribution strategy for hybrid packages: If you maintain or consume PHP packages that ship frontend assets (JS/CSS bundles, build outputs), this plugin lets a single composer require/composer update also pull the package's declared npm dependencies — collapsing two install steps into one for downstream consumers.
• Build vs. buy on install orchestration: It answers the question, "Do we write our own Composer plugin + post-install script to run npm install for package-declared JS dependencies, or adopt an existing one?" A 77-star, MIT-licensed, single-purpose plugin is cheap to trial — but see the archived-status caveat below.
• Roadmap input for package SDKs/marketplaces: Relevant if your product ships a plugin/extension ecosystem where third parties contribute packages that need both PHP and JS artifacts. This defines a contract (extra.npm-style declarations) you could standardize on, or deliberately reject in favor of "ship compiled assets, no runtime npm."
• Use-case fit: Best suited to internal monorepo-adjacent tooling, legacy Laravel apps that already mix Composer and npm workflows, and packages whose JS is a hard dependency rather than an optional enhancement.
• Non-decision: It is not a frontend build tool and does not replace Vite/Laravel Mix, asset versioning, or CI caching. Treat any proposal framed as "this solves our asset pipeline" as scope confusion.

When to Consider This Package

Consider it only when all of the following hold:

• You are maintaining a package (not just consuming one) that genuinely must ship npm dependencies alongside PHP code, and you want consumers to get both from one Composer command.
• Your team has the appetite to vendor or fork it: the repository is archived, the last release is November 2020, and no further fixes, security patches, or Composer/PHP version bumps should be expected.
• You have verified it works against your current Composer major version, PHP version, and npm/node toolchain — 2020-era assumptions about Node, lockfiles, and Composer plugin APIs are a real compatibility risk.
• You accept the operational cost: installs now depend on a live npm registry (or your mirror) at Composer time, which affects CI reliability, air-gapped builds, and reproducible deploys. You need lockfile discipline and registry mirroring in place.

Look elsewhere — strongly preferred — when:

• You are a consumer, not an author. The conventional and lower-risk pattern is for packages to ship pre-built assets and expose them via publishable resources (e.g., Laravel's publish tags, spatie/laravel-package-tools). No npm at install time, no plugin, no archived dependency.
• You need maintained software. For a maintained alternative to "Composer pulls frontend packages," evaluate oomphinc/composer-installers-extender with an asset repository (asset-packagist) for third-party JS libs, or simply run npm/yarn/pnpm in CI. For Laravel specifically, Vite plus committed or CI-built assets is the supported path.
• Supply chain and audit matter. An archived plugin sitting in the Composer plugin path (which executes code during install) is a meaningful, hard-to-remediate risk surface for anything customer-facing or regulated.
• Air-gapped, hermetic, or reproducible builds are required — this adds a network dependency at install time that you will have to work around.
• You need active support, SLAs, or a security response process. None exist here.

Decision rule: adopt only as a short-term, internal, forked-and-pinned bridge while you migrate to shipped assets; do not make it a platform dependency.

How to Pitch It (Stakeholders)

Executives: This is a small, MIT-licensed utility that lets a PHP package pull its JavaScript dependencies through Composer, so consumers get PHP and frontend code in one install. The strategic read is cautionary: it is archived and last released in 2020, with 77 GitHub stars and no maintenance path. That makes it a tactical tool, not a platform bet. Recommendation: permit it only as a short-lived, internally forked bridge in non-critical tooling, and fund the migration to shipping pre-built assets — which removes the dependency entirely and reduces install-time and supply-chain risk.

Engineering: The plugin hooks Composer install/update events to install npm dependencies declared by packages. Two consequences to plan for: (1) it executes third-party code in the Composer plugin path and is unmaintained since 2020 — pin a fork, audit it, and treat it as frozen; (2) it introduces a live npm registry dependency at Composer time, so CI needs registry mirroring, lockfile pinning, and offline-build fallbacks. Verify compatibility with our current Composer/PHP/Node versions before committing. Default alternative: packages ship compiled assets and publish them (Laravel publish tags / laravel-package-tools), with npm run in CI — same outcome, no archived plugin, no install-time network calls.