[RFC] Use different package manager for web assets

[craigh]

Please continue the discussion begun in #1714 in this ticket regarding the possible use of some other package manager for management of web assets like Bootstrap, jQuery, etc.

Current solution is to use components/components with the package manager component-installer. While this is currently a working solution, it has frustrations. My main complaint is that in order to use an updated asset, the shim repo at components/ must be updated manually, then if needed both the Zikula Bundle and finally the Zikula Core must also be updated. This is cumbersome and also dependent on the components repo to be up to date.

Another possible solution is to use bower or use bower with bowerphp. Here is an article about Using Bower in a Symfony2 Ap and another that leads me to believe using bower alone might be the best solution. Of course this would require developers to install bower like installing composer and also require some additions to the CI build process.

@Drak raises a reasonable concern about the installation location of the web assets using another (non components-installer) approach. It appears however, that bower can be configured to install the assets anywhere.

here is the SpBowerBundle that claims to "handle asset dependencies with bower" but I have not investigated this fully.

here is a package manager comparison: https://github.com/wilmoore/frontend-packagers

here is an article discussing whether front end assets might better be checked in to source control anyway. Which is an interesting thought. Since we have a CI process, this is probably not preferred however.

Your opinions?

cc: @Drak @cmfcmf @Guite

[cmfcmf]

Thank you @craigh for this summary / overview. As an example how we can use it, see #1720. This installs any bower assets without the need of installing any extra dependency (not even bower, as it uses PhpBower) on the dev-pcs in the javascript folder. @Drak I understand that this is not the end game plan, but IMHO it's better than adding it directly as in #1714.

[phaidon]

👍

[ghost]

I dont see how this can work, here's why:

1. Zikula needs one dependency manager, not two. Bower and composer cannot talk to each other. ModuleA depends on jQuery, Bootstrap,AnguarJS for example.
2. All code, modules will not be in the webroot at all in the future
3. All bundles/modules/themes are their own package and any assets are copies out by the kernel to the webroot, or symlinked.
4. Composer Component Installer already solves this. The extra step of having bundles is just a temporary workaround for 1.4. This goes away entirely, unless the bundles have functionality attached to them.
5. In the future we'll probably use embedded composer so zikula becomes a single file like composer which you just type zikula install after adding a composer.json.

I don't see what bower is actually solving for us, except removing the need to not have a shim repo... and actually, in many case the better solution is just making a PR to upstream to add a composer.json to their project. Is this really such a big deal?

For developers making a website they can do whatever they please outside of Zikula, there is no need to follow Zikula's paradigm for anything - as I have said, in most cases just adding a CDN include to template is enough.

[craigh]

I guess my first question then is how are other Symfony developers solving this? Surely we are not the first to have this concern. The two articles I linked seem to answer this at least anecdotally. At least some Symfony developers are using bower and composer together.

But, we are a modular system and they are making one project. Does this truly matter? Only if dependency matters. I don't think I've ever seen a PHP Lib dependent on a JS lib or vice versa. So this seems to be a false argument. PHP libs depend on other PHP libs and JS libs on JS libs, but they don't seem cross paths. And saying a "module" may have both dependencies can be true, but this doesn't mean within that they depend on each other. In this case they could still use both composer and bower.

location of files also seems to have been answered. Bower can place the files anywhere you like.

What is Bower solving? It is making our JS asset dependency much simpler and more current. we would only be dependent on the third party JS lib we want to use, since bower imports directly from the vendor. We would not be dependent on a chain of other projects in the middle getting updated (vendor -> component -> subBundle -> Core).

So, maybe I do not understand your concerns. If so, please help me understand. But It seems this would be a better solution. At least in the short term (Core 1.x)

[Guite]

Maybe this experience can be useful: http://tech.arendjantetteroo.nl/blog/2013/11/06/switching-from-bower-to-composer-with-components/

[ghost]

I think you are missing a detail.
Symfony is a web framework. You build your web application up using it. It is not a dynamic system and you dont need to worry about dependencies. You could use bower, composer and mix as many things as you want in, because you are in control of the system.

Zikula aims to be a ready made platform which you can install modules into. These will need to just work, out of the box and resolve dependencies. So module x depends on typeahead.js which depends on jquery. All of that should be resolved from the module x manifest. If typeahead requires jquery, that would be resolved automatically. If we have different package managers that will not work.

These days I am working with pure symfony and silex, to build some applications and it's very easy to manipulate because I am in control, and I have command line access. I can fiddle, customise. It doesnt matter if I need some JS packages, if I need them, I can get them use bower, manually include them whatever.

That's the difference. Zikula needs one package manager, two will not work because they do not understand eachother's needs.

[craigh]

I am still struggling to understand this. especially more after reading PR #1728 .

It appears that this new color picker library is not dependent on components while still using a zikula bundle.

Am I understanding this correctly? If this is true, why are we not doing this with all JS libs?

cc: @Drak @phaidon

[ghost]

@criagh it is using Composer Component installer. That doesn't have to be in the components org. Ultimately it's point to this shim https://github.com/claviska/jquery-minicolors

[craigh]

so how come we can't do this with other libs like jQuery?

[ghost]

We do already

[phaidon]

so how come we can't do this with other libs like jQuery?

I think because jquery-minicolor has a composer.json file and jquery not.

[ghost]

I'm getting ready to close this discussion because I can't see using two package managers for core. That's totally against the paradigm.

[craigh]

@phaidon - maybe it is because query-minicolor has a component.json file and jQuery does not.

[craigh]

Ultimately it's point to this shim https://github.com/claviska/jquery-minicolors

@Drak - that's not a shim. that's the actual repo.

[ghost]

@craigh if you want to avoid shims, encourage upstream authors by submitting PRs to them. For those that refuse, shims are the answer for the time being.

[craigh]

@Drak - I sure wish you would be open to discussion and willing to help me learn.

FTR - I've just been doing some research and it appears both bootstrap and jQuery have had discussions about supporting the components package manager and decided not to do so (in favor of bower). Long, "Holy War" discussions held in tickets in those projects over their unwillingness to simply add one tiny json file to their repo.

So, my point is, at least two of our most significant JS vendors will never be supporting components.

[ghost]

@craigh what is so wrong with adapting where needed (using shims). What is suggested in this ticket is an unworkable hack. Bower and Composer cannot understand each other or resolve each other's dependencies so the idea is dead before birth.

I personally dont understand why jQuery would refuse to add a component.json meta file as well as bower.json, but that is their own decision.

An innovation would be to make Composer component installer understand bower.json but until then, we are going to use shims.

[craigh]

An innovation would be to make Composer component installer understand bower.json but until then, we are going to use shims.

composer/composer#1121

[craigh]

what is so wrong with adapting where needed (using shims)

when forced to use the component repository, we are using an unofficial second copy of a repo. This secondary repo requires ongoing maintenance. It is a pain in the next.

[craigh]

I personally dont understand why jQuery would refuse to add a component.json meta file as well as bower.json, but that is their own decision.

jQuery doesn't even contain a composer.json file...

[craigh]

here's an idea for using a post-install script for Bootstrap: http://stackoverflow.com/questions/19118367/how-to-setup-bootstrap-after-downloading-via-composer