There were several performance-related issues on github, all of them are, luckily, closed.
I remember a debate with choosing the right solution to deal with bower assets. And it seems to me that it sabotages the framework’s ecosystem for now.
There are constant speed improvements in repo’s history. And the latest version still triggers asset updates on everyupdate package/name and require package/name. It gives extra 30 seconds on my machine even with default Yii widget dependencies.
Do you have any ideas on how to improve composer’s performance in scenarios when asset plugin just slows the things down? I’m about to fork it and stub its update urges, switching to the original fork only to solve bower dependencies.
Why should not it be? Composer is convenient and prompt utility to manage dependencies… well, it was. Nobody wants to make himself an excuse and go for a cup of coffee every time he needs to switch between package versions. But adding new packages concerns me much more.
Kill switch for asset processing is triggered with --ansi or --no-ansi Composer options, since there is no way for Composer plugins at present to add custom CLI options.
It is disabled automatically when bower-asset or npm-asset packages are submitted explicitly to command line.
It replaces the original plugin. The installation is similar,
php composer.phar global require "bisubus/composer-asset-plugin:dev-master"
