Bower - Root project configuration

[Ninir]

Hi,

While looking at your bundle in order to use it, I am facing the issue about ressources not being in bundles, but in web/assets/vendors. Thus, I can't really specify a bundle in the config, as my .bowerrc and bower.json files are in the root project.

Does is seem legit to you?

Would be happy to contribute if we agree on the best way to proceed :)

[matheo]

I would like to know how the sp_bower.allow_root works, because there are no references of it in the docs, and probably helps in this matter. I prefer to have this kind of root configuration too. Thanks for this bundle

[Spea]

Currently there is no such configuration. Right now, this bundle only allows to define bower deps for other bundles. However, I will start working on this feature soon, since it would be really nice to have, but I have to figure out, how I can integrate this in the current configuration-structure.

I would highly appreciate it, if you have any suggestions for this.

[rvanlaak]

Making use of bower on the root level of a project in my opinion also is a must-have. My main point for this is that the composer.json and bower.json file should be located in the same folder.

Any idea when this feature could be implemented?

[althaus]

:+1: for bower.json on project root.

[luishdez]

Not really sure about that idea. If components are not intended to be delivered within a bundle, why you don't use bower command directly? What will be the advantage?

[Ninir]

@luishdez Automation using a ScriptHandler for instance (one example)

[luishdez]

@Ninir that's the only one that I thought. But not sure if that worth it. I think that the value of this bundle is the ability to deliver bower components within bundles.

But add a feature just to avoid bower install command… And if you are deploying or testing for sure the are better ways than execute bower through composer.

Just my opinion, may be there are more practical cases. I dunno.

[Ninir]

@luishdez Well, the last thing is: a project "is" kind of a bundle, even if it is wrapped in an application. My resources are encapsulated in a /web dir, as explained above. I don't want to install them in a bundle, for ease of use/management.

My second argument for today would be: a lib/bundle should be configurable/extendable. This bundle is defined as "adds support for handling asset dependencies with bower in a nice way.". So why not handling assets in my project this way too? ;)

[Ninir]

@Spea What do you think about checking the existence of a bower file at the root project?

[Spea]

I think its a good feature to have. The main goal of this bundle was not to install the bower dependencies, but to be able to use the assets provided by those bower-deps, so it should not matter where you defined your assets (in a bundle or in any other location). I also already experimented with this a little and its not so hard to implement.

[Ninir]

@Spea If you have an hint on how to deal with it, please give it to us in order for us to help you ;)

[Spea]

I thought about doing it in the configuration for bundles, like this:

bundles:
    some_root_configiuration:
        config_dir: %kernel.root_dir%/Resources/bower 
        asset_dir: %kernel.root_dir%/../web/components 

So the idea is, that the bundle checks if the some_root_configiuration is a bundle name, and if not, the config_dir and asset_dir parameters are required and it will be treated as a root configuration.

The only thing which bothers me, is the fact that this is under the bundles parameter, which can be a little bit confusing. Maybe you have some better suggestion.

[luishdez]

In the meanwhile if someone wants to use bower in the root and manage it with composer.

.bowerrc

{
  "directory": "web/components"
}

bower.json

{
  "name": "my-project",
  "version": "1.0.0",
  "dependencies": {
    "jquery": "1.11.0"
  }
}

composer.json

{
    "scripts": {
        "post-install-cmd": [
            "bower install"
        ],
        "post-update-cmd": [
            "bower update"
        ]
    }
}

[rvanlaak]

I've used the way how @luishdez suggests to use bower with composer and it works nicely. It actually makes this bundle unnecessary, am I correct? ;-)

Making use of the bower components as assets in Twig also is possible using Assetic from /web/components

[Spea]

This bundle was never meant to "just" install bower dependencies, the main feature of this bundle is the automatic registration of the assets installed by bower. However, if you don't want to use them, you don't have to use this bundle.

[luishdez]

@Rvanlaak I find this bundle very useful, Eg: if you have a a bundle that uses bower you don't have to worry about where it's , just add to your config.yml spbower settings. This is useful to create shareable bundles that use bower.

[althaus]

@Spea Why not move the "root" config out of the bundles ns:

project:
    config_dir: %kernel.root_dir%/Resources/bower 
    asset_dir: %kernel.root_dir%/../web/components
bundles:
    AcmeDemoBundle:
        config_dir: Resources/config/bower
        asset_dir: ../../public/components 

Dunno wether to call it project, root, app or just move the sp_bower ns directly:

sp_bower:
    config_dir: %kernel.root_dir%/Resources/bower 
    asset_dir: %kernel.root_dir%/../web/components
    bundles:
        AcmeDemoBundle:
            config_dir: Resources/config/bower
            asset_dir: ../../public/components 

[Spea]

@althaus In both cases you can only specify one root configuration. I would prefer a solution where you can set multiple configurations, just like in the bundles section. Currently I think the best solution would be to rename bundles to projects and allow root-configuration beside bundle-configuration

[Ninir]

@Spea :+1:

[ghost]

@luishdez : you'll probably want to use this in the future

https://github.com/francoispluchino/composer-asset-plugin

It needs two patches to hit composer first though.

@Spea : it'd be cool to rely on this in the future also if it works well.