Streams Composer Plugin Laravel Package

Getting Started

This is a Composer plugin, not a library, so installation means registering it with your Streams application's root composer.json and letting Composer load it on every run. Install with:

composer require anomaly/streams-composer-plugin

Because it hooks into Composer's lifecycle, verify two things before anything else:

1. Composer 2 allow-plugins. On Composer 2.2+ plugins are blocked unless whitelisted. You will need "config": { "allow-plugins": { "anomaly/streams-composer-plugin": true } } or a --no-plugins bypass when you need a clean install. The package predates this rule (2015) so it will not self-declare.
2. Composer plugin API constraint. Open the package's composer.json and check require.composer-plugin-api. If it pins ^1.0, expect to patch the constraint or run a Composer 1 binary — this is the single most common blocker on modern stacks.

Where to look first:

• composer.json — inspect type, extra, and require to understand what Streams contract it expects.
• src/ — the Plugin class (activate(), deactivate(), and getSubscribedEvents()) tells you exactly which Composer events fire and what directories/files get touched.
• The README of the parent Anomaly/Streams distribution — addon conventions live there, not here.

First use case: adding a Streams addon (module, extension, theme, or plugin) to an existing Streams app and having Composer place and register it correctly without manual addons/ shuffling. If you are starting a brand-new Streams install, this plugin is a supporting actor — the platform distribution remains the entry point.

Implementation Patterns

Addon-side declaration. Streams addons ship a composer.json that declares a package type (typically a Streams-specific type such as streams-addon or equivalent) plus an extra block naming the addon, its namespace, and where it belongs. The plugin reads this metadata after install and wires the package into the app's addon paths. When you author or fork an addon, copy an existing package's extra block rather than guessing the keys.

Application-side integration. The plugin belongs in the root app's require (and now allow-plugins), never inside an addon. Addons stay plugin-agnostic — they only declare type and metadata. Keep that separation; it makes addons portable across Streams installs.

Lifecycle hooks. Expect subscriptions on post-install-cmd and post-update-cmd at minimum, and usually post-autoload-dump for path/autoload registration. Two practical consequences:

• composer install --no-scripts will skip the wiring, leaving addons unregistered. Use it deliberately for debugging, then follow with a normal composer dump-autoload.
• CI installs must run with plugins enabled; COMPOSER_ALLOW_SUPERUSER=1 on container builds plus the allow-plugins entry avoids surprises.

Local development loop. For an addon under active development, prefer a Composer path repository in the root app pointing at your working copy, with a symlink strategy so the plugin's placement logic and your live edits don't fight each other. Re-run composer update vendor/addon-name after changing the addon's extra block — the plugin reads it at install/update time, not on every autoload.

Deployment. Commit composer.lock, run composer install --no-dev with plugins enabled on the target, then verify the addons directory was populated and the registration file (if the plugin writes one) is present and git-ignored or committed consistently across environments.

Gotchas and Tips

This package is effectively abandoned. Last release July 2015, one star, zero dependents. Treat any adoption as maintenance-inheritance: fork it, vendor the fork, or expect to patch it yourself. Pin the fork by VCS repository rather than relying on Packagist.

Composer 2 compatibility is the first wall. Older plugins frequently use removed APIs (Composer\Plugin\PluginInterface signature changes, deprecated event names). Symptoms are a fatal during activate() or a silent no-op where nothing is placed. Debug with composer install -vvv and watch for the plugin activation line — absence of that line means it never loaded (allow-plugins, API constraint, or --no-plugins).

Silent failure modes. Plugins that only log at -v and above will appear to succeed while doing nothing. After any install, confirm the actual side effect: files in the addons path, a regenerated registration/config file, or correct autoload entries — not just exit code 0.

Idempotency and re-runs. Check whether the plugin guards against re-running its placement logic. If it copies rather than symlinks, composer update can overwrite local modifications to an addon. If it symlinks, be aware Windows and some CI filesystems will not follow the links.

Paths and permissions. The plugin writes outside vendor/. On hardened deployments (read-only release dirs, non-writable addons/), activation will fail or partially write. Either make the target writable during install or run the install step in a build stage and ship the result.

Extension points worth auditing. The getSubscribedEvents() method is your map: events it hooks, priorities, and any methods calling getIO() for interactive prompts. Interactive prompts will hang non-interactive CI — pass --no-interaction and check the plugin handles that path.

Fallback plan. Because support is gone, keep a manual escape hatch documented: the equivalent of dropping the addon into the addons path and registering it by hand. Knowing the manual steps makes failures recoverable and lets you migrate off the plugin later without re-architecting your installs.