Closed dsdobrzynski closed 8 years ago
Not sure why you would want to use Composer to install a javascript library.
Mainly this comes into play when people are using a particular back-end technology (PHP, Perl, Python, Ruby, .NET) but want to manage their client-side code using the same package manager. We started down this road with jQuery core, trying to support more package managers, and backed off. It adds more burden on the repo authors by pulling them into supporting unfamiliar ecosystems.
As long as the file is available in final form with a compatible module loading format (e.g. UMD) it is possible for someone else to add support for any package manager. Here are some examples:
https://github.com/rocsci/jquery-easing-rails
https://atmospherejs.com/mrt/jquery-easing
https://www.atomikos.com/System/PerlDoc?module=Foswiki::Plugins::JQueryPlugin::EASING
@dmethvin is correct. Using one package manager simplifies management. Supporting multiple package managers seems to be becoming more common as well. As far as increasing the burden on repo authors, open source packages can make use of the wider community. Those familiar with other ecosystems can add support without the repo authors having to learn other ecosystems. I think the challenge then becomes where to draw the line as far as adding support for additional package managers.
Since the repo already uses npm for its own needs it seems easy to provide npm support. The others, not so much.
I understand what it is :) this just seems like the wrong use case for it – composer is for server side dependencies. I'm closing this as I don't think it adds anything. It's already possible to add non-composer packages if you really need to include it that way.
Add composer.json for composer support.