Handled by Frameworks instead of Package Managers?

[Beau Simensen]

Individual frameworks are more likely to care about where frontend assets need to be placed. Proposing the package managers managing the frontend packages might be difficult as it would require a lot of extraneous configuration and might be a tough sell to the big package managers.

On the other hand, if the Framework is in charge of managing its own frontend dependencies (independent of whatever is managing its library dependencies) it would have more control over where things are placed.

So support for this repository could be added to rails instead of to gem/bundler/whatever. Support could be added to Symfony, Zend, Cake, etc instead of to Composer.

I think this might fall into the "building a package manager for the css/js community" category, but with a slight twist in that it won't be a standalone tool that everyone will have to use. It would be built into individual frameworks instead of into individual package managers.

In some cases this might be by way of a 3rd party application. Maybe Cake doesn't provide this natively but someone writes a cake-frontend-package-manger application that can be used to install frontend packages into a cake project. In other cases it might be a first class citizen of the framework in question. For example, it could be added as a built in rails command or a symfony standard console command.

[Beau Simensen]

Any thoughts on this idea/these questions, one way or another?

This list seems pretty quiet. Has there been any traction off this list in getting anyone else interested in tackling this problem?

[Martin Prebio]

The metadata for a given frontend package won't differ between two different frameworks. Even if one is Zend and the other is Django, the name, dependencies, etc should stay the same. At least I can't think of any counter-example.
For PHP Projects which uses composer there could be a custom installer that is framework-specific. Eg. ZF1 gets a ZF1-Frontend-Installer, ZF2 a ZF2-Frontend-Installer and Symfony a Symfony-Frontend-Installer which all implement an abstract Frontend-Installer. Other languages and PHP projects could implement this schema on their own.

After this semester's test season I'll implement something like this for ZF1, maybe if there's interest, I'll do it like I've explained here.

[Jordi Boggiano]

Heya,

> Individual frameworks are more likely to care about where frontend
> assets need to be placed. Proposing the package managers managing
> the frontend packages might be difficult as it would require a lot
> of extraneous configuration and might be a tough sell to the big
> package managers.

Well the idea is that packages describe themselves well enough that the
installer (through configuration in composer.json in our case) can do a
decent work of putting files where they belong.

> So support for this repository could be added to rails instead of to
> gem/bundler/whatever. Support could be added to Symfony, Zend, Cake,
> etc instead of to Composer.

I don't think you can separate them, because your app's packages depend
on the frontend packages, so it means you'd have to describe those
dependencies to the framework.

> Any thoughts on this idea/these questions, one way or another?
>
> This list seems pretty quiet. Has there been any traction off this list
> in getting anyone else interested in tackling this problem?

The only feedback I got was that there is a solution called volo [1]
that seems quite interesting, but is hardly complete, and is also
another package manager, so right now it does not really help us. If it
had centralized metadata I would happily add support for that.

The other thing I got is that some twitter guys are working on
something, but nobody felt like giving any more details. Sounds like the
typical "open source" process where you push something on to the crowd
and they better like it. A bit disappointing, but since I don't have
time to do anything on my own at the moment, I'm happy to wait and see
what comes out.

Cheers

[1] https://github.com/volojs/volo

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