[feature] supporting "not only php" ... twitter/bootstrap for example

[brikou]

It is not an issue but working on php project involve sometimes more than php libraries but for example JS library or even bulk library. I think for example about http://twitter.github.com/bootstrap/

We could define a composer file for this github project which could be used with assetic (supporting less in this example), what do you think about supporting this kind of library?

cheer

[Seldaek]

Of course I think it's great. The only question, and it's not a small one, is how to do this best? How to make it generic so it can benefit everyone, etc.

[digitalkaoz]

i successfully managed to get other non-php stuff workin with composer, here is my config:

    "repositories":[
        {
            "type":"package",
            "package":{
                "name":"elastic/search",
                "description":"elasticsearch",
                "version":"0.19.1",
                "dist":{
                    "url":"https://github.com/downloads/elasticsearch/elasticsearch/elasticsearch-0.19.1.zip",
                    "type":"zip"
                }
            }
        },
        {
            "type":"package",
            "package":{
                "name":"twitter/bootstrap",
                "description":"twitter bootstrap",
                "version":"2.0.2",
                "dist":{
                    "url":"http://twitter.github.com/bootstrap/assets/bootstrap.zip",
                    "type":"zip"
                }
            }
        },
        {
            "type":"package",
            "package":{
                "name":"mrdoob/threejs",
                "description":"three js",
                "version":"0.48.0",
                "dist":{
                    "url":"https://github.com/mrdoob/three.js/zipball/r48",
                    "type":"zip"
                }
            }
        }
     ]

so its already working right now, but i dont think that was the intedation of this issue?!

[brikou]

@digitalkaoz ok I've made it I thought that some parameter like autoload were mandatory... great

{
    "repositories": [
        {
            "type": "package",
            "package": {
                "name": "twitter/bootstrap",
                "version": "master",
                "dist": {
                    "type": "zip",
                    "url": "https://github.com/twitter/bootstrap/zipball/master"
                },
                "source": {
                    "type": "git",
                    "url": "https://github.com/twitter/bootstrap.git",
                    "reference": "master"
                }
            }
        }
    ],
    "require": {
        "twitter/bootstrap": "*"
    }
}

@Seldaek what would be really great with this kind of configuration file, would be to define a generic package and not one for each version. Here is what I wish config was... defining some kind of variable like version

--- composer.json       2012-04-03 19:10:19.266783100 +0200
+++ composer.json.new   2012-04-03 19:10:16.089602300 +0200
@@ -4,20 +4,19 @@
             "type": "package",
             "package": {
                 "name": "twitter/bootstrap",
-                "version": "master",
                 "dist": {
                     "type": "zip",
-                    "url": "https://github.com/twitter/bootstrap/zipball/master"
+                    "url": "https://github.com/twitter/bootstrap/zipball/v%version%"
                 },
                 "source": {
                     "type": "git",
                     "url": "https://github.com/twitter/bootstrap.git",
-                    "reference": "master"
+                    "reference": "v%version%"
                 }
             }
         }
     ],
     "require": {
-        "twitter/bootstrap": "*"
+        "twitter/bootstrap": "2.0.2"
     }
-}
+}

Tell me what you think of it ;)

[stof]

another issue about non-php packages is that the location matters. For PHP code, they can be installed in a location chosen by Composer (as it handles configuring the autoloader accordingly) but bootstrap would need to be installed in your web root to make the assets available

[digitalkaoz]

yeah i symlinked it, to make it work, but thats not the best way to go

it must be configurable for non-php stuff where relative to vendor it should be installed...think of java components or something...you wont want to have them in your webroot

[stanlemon]

What would be nice is if package repositories could define their own respective vendor dir, ie. I could designate "vendor-dir": "webroot/lib" for example

[ghost]

@stanlemon I don't think you can get the package repos to specify the vendor dir, but in the require statements, it would be good to be able to override the default vendor-dir settings. I already discussed this with @Seldaek

[mvriel]

Couldn't this be solved with a new type asset that uses a Custom Installer AssetInstaller that takes it's root path from the extra section?

[ghost]

@mvriel or what about a type called 'require-extra' which is defined by vendor => array(version, path)

e.g.

    "require-extra": {
        "foo/bar": ["1.2.3", "vendor-dir"],
    }, 

This way it can truly work for anything. There are other usecases for example system modules e.g. in Zikula or Drupal where modules sort of need to go in a special folder.

[igorw]

@mvriel I like that idea a lot!

[stanlemon]

FYI, I was thinking something more akin to what is mocked up here: https://github.com/stanlemon/composer If there's any interest I'll issue the pull request.

[stanlemon]

And here's what I imagined the config might look like:
https://gist.github.com/2338958

It might be better to name "install-dir" as "vendor-dir", I wasn't sure if the namespace overlap would be confusing or help.

[Seldaek]

@brikou: Your package template idea is interesting I think, but please open that in a separate issue so it can be discussed there.

[Seldaek]

I think the only way this can be done in a flexible enough way so it works for everyone, as I hinted at before, is to specify these asset things in the main package, and not in the installed packages themselves. Here is how it could look:

{
    "repositories": [ "... (standard twitter bootstrap thingy, does not matter) ..." ],
    "require": {
        "twitter/bootstrap": "*"
    },
    "assets": {
        "twitter/bootstrap": {
            "js/*.js": "web/js/",
            "less/": "web/less/bootstrap/"
        }
    }
}

This basically describes which files to copy where for a given package. All source paths (left) are relative to package dir, and target paths (right) are relative to project root (composer.json's dir).

I think this would be a good first step that allows very flexible setups and shouldn't be too hard to implement as we've seen with the PRs by @mvriel and @stanlemon which already do a somewhat similar thing.

As a second step, and please note that I'm just throwing the idea out there, I could imagine that packages themselves define their assets, but the project would still define where they are placed. This is less flexible, but might make for shorter configuration:

{
    "repositories": [
        {
            "type": "package",
            "package": {
                "name": "twitter/bootstrap",
                "version": "master",
                "dist": {
                    "type": "zip",
                    "url": "https://github.com/twitter/bootstrap/zipball/master"
                },
                "less": ["less/*.less"],
                "js": ["js/*.js"]
            }
        }
    ],
    "require": {
        "twitter/bootstrap": "*"
    },
    "assets": {
        "@less": "web/less/",
        "@js": "web/js/"
    }
}

As you see there, you can't really define everything granularly in the assets, you just say all files tagged with this @less go into one directory, that probably would end up as quite a mess, maybe we need to add a package name or something in there. Anyway it's just an idea.

Please comment, especially on the first concept, whether you think it's workable or not.

[digitalkaoz]

i like the first approach

[brikou]

This kind of configuration file makes would allow very powerful usage, great...

[naderman]

I think requiring people to specify this in the main package for every dependency, and dependencies of dependencies, etc. is really poor usability. So I really don't like the first approach. We should do something along the lines of the second:

My proposal:

twitter/bootstrap:

"assets": {
    "js/*.js" : "js",
    "less/": "less",
    "foo/images/": {"type": "img", "prefix": "prf/"},
    "bar/sub/*.png": "img"
}

All js files will be installed into web/js/ and all less files into web/less retaining whichever directory structure they were in, in the original package. So this would result in:

"js/foobar.js" => "web/js/foobar.js"
"less/foo/bar.less" => "web/less/foo/bar.less"
"foo/images/foo.png" => "web/img/prf/foo.png"
"bar/sub/bar.png" => "web/img/bar/sub/bar.png"

By default the config for "asset-dir" will be "web/" to install all assets of all packages to "public" instead add this to your main package config:

"config": {
    "asset-dir": "public/"
}

You can set asset-dir to false if you don't want assets to be installed.

To exclude assets from a package add to your main package config:

"assets": {
    "exclude": ["twitter/bootstrap"]
}

To exclude one type of assets from a package add to your main package config:

"assets": {
    "exclude": [{"package": "twitter/bootstrap", "type": "less"}]
}

To exclude certain files from a package add to your main package config:

"assets": {
    "exclude": [{"package": "twitter/bootstrap", "files": ["js/some.js", "bar/sub/*"]}]
}

[Seldaek]

I'm generally ok with that, a few comments though:

• "foo/images/": {"type": "img", "prefix": "prf/"}, could be rewritten as "foo/images/": "img/prf/", ?
• I would maybe default asset-dir to false, because I'm not sure if web is really a major winner in that category.
• I don't like too much that the exclusion is done in the same assets key as the one defining assets because it potentially conflicts and especially it may be confusing, since I guess excludes are only available to the root package. It's easier to explain what is root only and what not if the differences are only on top level keys. Maybe "asset-excludes": []?

[naderman]

• Well you could and it would certainly be easier. But it needs to be clear that the first directory represents the asset type for matching in exclude. A problem would be that "foo/images": "img" should result in "img/foo/images/x.png" according to the other examples I gave, so how do you describe "foo/images": {"type": "img", "prefix": ""} then?
• Indeed asset-dir = false it is
• Yes, was thinking that myself already. I'd use "assets-exclude": [] (singular exclude, inline with other options).

[stof]

The issue with this proposal is that it is really easy to have conflicts between assets of 2 packages (meaning you cannot rely on these assets as the one you will really get depends of the order in which Composer installed the packages). We need a way to avoid conflicts.

[Seldaek]

Well you can exclude conflicting assets from a given package to resolve
it. I guess we could build up the complete list of things to be copied
before copying anything so that we can warn if there are conflicts.

[naderman]

Indeed, I think as long as we warn (or error?) on conflicts, and allow the user to exclude and manually deal with assets they exclude, this should be ok.

[RobLoach]

Grunt is a task-based command line build tool for JavaScript projects. It would be neat if we could pass some instructional data through "extra" to have Assetic build the required assets, similar to how Grunt works.

[mneuhaus]

I'm using bower currently for my Web Assets, which sucks compared to composer, so consider this my +1 :)

[RobLoach]

Speaking of Bower, they're interested in getting their components working in Composer:
components/jquery#3

That pull request adds a composer.json file to components/jquery. I'm sure the schema for defining assets needs work, but it is an interesting idea. Would be nice to write a require.js file from the defined components. https://github.com/robloach/components .... I also like the design behind http://github.com/component .

[rawtaz]

Why can't you just make it so that in the project's composer.json file, where one define which packages to pull in, one can define which target folder a package should be installed to (instead of the vendor/ folder)?

I can think of reasons to make it possible to be specific per files/assets in a package, as per this discussion, but just being able to do the most basic act of relocating one or more packages as needed to whichever folder one wants them to be in will be good enough for most people, and it solves the main problem in general.

It also does not prevent you from adding fine grained controls atop of that if you want. On the other hand, not being able to do this simple relocating will just make you have to enter a lot more configuration to relocate all of the assets in a package if you want to do that. Hence, even if you implement the fine-grained control, keep a basic "targetDir" setting or similar as well.

Personally I just need to put bootstrap in a public place and that's all. I don't need to fiddle with the individual parts of it when relocating it, having it in /bootstrap/ is just fine for this project.

Thanks!

[RobLoach]

Although it's still quite young, that's the plan with http://robloach.github.com/component-installer .

{
    "require": {
        "components/jquery": "*"
    },
    "config": {
        "component-dir": "public"
    }
}

Been putting a bit of time into a repository builder that parses through the data on http://component.io. Might post the beginnings of it tonight. If you'd like to help out, stick up an issue in http://github.com/robloach/component-installer and I'd love to chat.

[reinier]

What rawtaz describes is exactly what I need. I don't need the extra options of relocating JS and CSS to different kind of folders, I just need to relocate the bootstrap directory to a public directory. That's it.

[mnapoli]

@reinier yes, that is what you need.

[spenat28]

@rawtaz yes, thats exactly only think i need from composer right now

[rawtaz]

@mnapoli Your comment is pretty pointless. Yes, it is what @reinier needs, but as you can see it is what others need as well. It's also still a very basic feature, not overcomplicating things. And again not preventing other more complicated features like those that have been discussed earlier in this thread.

[mnapoli]

The point I was trying to make was that composer is an open source project and it tries to solve everybody's problems (at least most people's problems) with dependencies. So instead of "I want that, I need that, that's it", let's try to think for more than just our own use case.

[pscheit]

are there plans to developing this into one specific direction? Is someone having a glance at this? Is it still a current feature?

[rawtaz]

It seems like no, apparently this is not something the Composer guys want to implement. The main argument seems to be that "Composer is for PHP dependencies", which I find pretty darn vague. Why does it have to be for PHP only, when it would be so simple to just let us pull in whatever other packages we want? It's just files, for gods sake.

Having to juggle multiple dependency managers when one has only basic needs is pretty pointless. Again, I haven't seen any relevant arguments other than some vague opinion-based one which doesn't have a real point to it. I'm very open to hearing more concrete reasons why this cannot or should not be done.

[rawtaz]

Have the same use case right now, again. Need Bootstrap, have Composer, not interested in pulling in some other more "CSS-focused" manager like Bower or what not.

[CMCDragonkai]

Can composer download a single text file? I've read somewhere that there is a "file" type? But this isn't documented anywhere?

[Anahkiasen]

If you want to install front-end dependencies use Bower. Trying to use Composer for this is like trying to use NPM to install Ruby gems.

[pscheit]

put everything on npm! ;)

[garak]

Something like http://bowephp.org/ ?

[cebe]

If you want to install front-end dependencies use Bower. Trying to use Composer for this is like trying to use NPM to install Ruby gems.

The problem with using two package managers is that if you have a package that has dependencies on PHP packages as well as on javascript/css packages you can not resolve these dependencies in one step and do not get notified about confliciting requirments easily.

Best solution imo would be if composer could have an installer that uses something like bowerphp to accees the bower repository and install packages from there. Most jquery libs refuse to add composer.json to their repo because they are not php libs.

[Anahkiasen]

Do you have an example of package that has both front end and back end dependencies ?

[cebe]

https://github.com/yiisoft/yii2/blob/master/composer.json#L71

[cebe]

In general every modern php web application has some php libs for server side and javascript libraries for client side.

[jaylinski]

i wrote my own little post-install-script to copy assets to the public folder:

{
    "autoload": {
        "psr-0": {
            "Installer": "PathToInstaller/"
        }
    },
    "scripts": {
        "post-install-cmd": "Installer::postInstallCmd"
    },
    "extra": {
        "assets": {
            "destination": "vendor/package/assets/"
        }
    }
}

inside my post-install-script, theres a recursive file-copy function that copies the source to destination:

$extra = $composer->getPackage()->getExtra();

// copy assets to public folder
if(is_array($extra)) {
    if(array_key_exists('assets', $extra)) {
        foreach($extra['assets'] as $destination => $source) {
            $destination = __DIR__.self::PUBLICPATH.$destination;
            $source      = __DIR__.self::SRCTPATH.$source;
            try {
                self::recurse_copy($source, $destination);
                echo 'Copied assets from "'.realpath($source).'" to "'.realpath($destination).'".'.PHP_EOL;
            } catch(Exception $e) {
                echo 'Error: Failed to copy assets from "'.realpath($source).'" to "'.realpath($destination).'".'.PHP_EOL;
            }                   
        }
    }
}

hope this helps someone.

[alcohol]

/cc @Seldaek is this still something you want to keep open considering the popularity of https://github.com/francoispluchino/composer-asset-plugin ?

[Seldaek]

Yeah I think we can leave that in the plugin for now, it can always be revisited later if it makes sense.