Build on top of composer
You should use code from composer and not inventing the wheel. I suggest to use VersionParser, JsonFormatter, DependencyResolver, Downloader etc.
That was an option we considered when we started this project. But we soon realized that the packagist system is really different from the bower one, so depending on composer is just a mess. I agree that some classes could be usable, but unfortunately they are just inside composer and not available as separate components.
How about using composer/composer as a whole? It's not a huge deal to have a few extra classes you don't use on disk IMO, that's the case with pretty much any library you are going to use.
@garak what are the chances of reconsidering using composer as a whole like @Seldaek mentioned? Would it be a mess to use just those classes that "could be usable"?
It's not a current priority. BTW, Seldaek's comment in above linked issue is not reassuring me.
@garak it's just a pain to develop things in isolation when you need to patch multiple subsystems to add functionality. Most things are usable more or less standalone they just depend often on a Config and IO instances. That's all I was saying.
Thanks for you clarification Jordi. I still believe that problems of refactoring to use composer are bigger than benefits, at least for now.
You might be underestimating how much more you will have to fix in these parts before it works correctly, the effort to maintain this, and the missed opportunity to integrate these two tighter to cover both frontend and backend needs via composer.
Another solution based on composer https://github.com/francoispluchino/composer-asset-plugin