Thoughts on a front-end capable Composer

[Jarrod Nettles]

My name is Jarrod Nettles -  I too have been grappling w/ the problem of front-end libraries. I had even started preliminary work on a package manager similar to Composer - but after reading Nelmio's blog post and I'm in total agreement that we need a single, unified package manager for PHP + frontend and there's no reason why Composer couldn't deliver on both of these fronts.

Here's a couple of reasons, as far as I see it.

• I'd say 95% of the projects I use Composer w/ are web-facing commercial projects (i.e. - have some sort of front-end aspect).
• When I'm starting a new site and listing my PHP dependencies - my next step is to go hunting and running wget on all the UI libraries that I need and dumping them into a scripts/css folder.

I know that the original question is posed as a "universal" repository in addition to front-end libs (encompassing even Ruby, Java, .NET, etc.) but honestly I think we would be better served to keep our discussion and efforts razor-focused on delivering the best solution for front-end packaging that we possibly can to the PHP community. I think that we could spend forever chasing our tails w/ the Ruby and Java community and not getting anywhere trying to determine a common ground of metadata and package needs.

The solution to me seems fairly straightforward - extend composer to include the ability to require and require-dev front-end libs. 

[Jordi Boggiano]

Heya,

> I know that the original question is posed as a "universal" repository
> in addition to front-end libs (encompassing even Ruby, Java, .NET, etc.)
> but honestly I think we would be better served to keep our discussion
> and efforts razor-focused on delivering the best solution for front-end
> packaging that we possibly can to the PHP community.

Composer does and will still do that.

> I think that we
> could spend forever chasing our tails w/ the Ruby and Java community and
> not getting anywhere trying to determine a common ground of metadata and
> package needs.

Let's not be so pessimistic. As I said in my blog post, all it takes is
a few persons that are motivated and open minded enough to put the silly
language wars on the backburner for a while.

> The solution to me seems fairly straightforward - extend composer to
> include the ability to require and require-dev front-end libs.

You are missing my point I think. That's what I suggest. But if we do
that, we need metadata for the frontend libs. If we have metadata. We
might as well share it with other tools instead of building
Composer-specific stuff that nobody else can reuse. It's the only way to
possibly gain acceptance from the frontend guys too.

The way Composer works, and most other package managers work in the same
way, is that you have package metadata/listings, and then packages. You
read the listings to know what to install, then you download the actual
packages and install that. This is all just data, it can be read and
shared by everyone, and it should be. Composer would still have its own
way of installing the packages, that may differ from other tools.

I hope this clarifies it a bit.

Cheers

--
Jordi Boggiano
@seldaek - http://nelm.io/jordi

[Jarrod Nettles]

I think I understand more clearly the point you're trying to drive at.

Frontend package maintainers - they aren't going to want to maintain multiple management systems - Composer, PyPm, Gems, etc. So is the real problem you're trying to solve how do we create a unified standard for frontend packages so that maintainers can push once - and be available a diverse community of package managers? That's the issue I'm seeing here. Sorry if I'm being slow here - I've been out all week and this is basically my Monday. :)

[Jordi Boggiano]

On 31.05.2012 20:42, Jarrod Nettles wrote:
> I think I understand more clearly the point you're trying to drive at.
>
> Frontend package maintainers - they aren't going to want to maintain
> multiple management systems - Composer, PyPm, Gems, etc. So is the real
> problem you're trying to solve how do we create a unified standard for
> frontend packages so that maintainers can push once - and be available a
> diverse community of package managers? That's the issue I'm seeing here.
> Sorry if I'm being slow here - I've been out all week and this is
> basically my Monday. :)

Yes, that's basically it. Except I also want to cut out the lib
developers from the picture (at least at first), because that way it's
easier to support all libs, whether they care or not.

[Jarrod Nettles]

You mean cut out the frontend lib developers from the process so they don't have to explicitly provide metadata for their projects in order to appear as a valid package?

[Tomi Saarinen]

I definitely cheer for the idea. But I also think all the best interfaces and standards are based on several iterations of practical and revised implementations. So I guess what everyone needs is an actual proof-of-concept implementation of the idea. It would also make the idea easier to grasp. The initial implementation could be done, e.g. on Composer, as long as it is acceptable to fully redefine and rewrite the implementation if feedback requires it.