New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
brikou opened this Issue Apr 3, 2012 · 46 comments

Comments

Projects
None yet
@brikou
Contributor

brikou commented Apr 3, 2012

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

This comment has been minimized.

Show comment
Hide comment
@Seldaek

Seldaek Apr 3, 2012

Member

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.

Member

Seldaek commented Apr 3, 2012

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

This comment has been minimized.

Show comment
Hide comment
@digitalkaoz

digitalkaoz Apr 3, 2012

Contributor

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?!

Contributor

digitalkaoz commented Apr 3, 2012

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

This comment has been minimized.

Show comment
Hide comment
@brikou

brikou Apr 3, 2012

Contributor

@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 ;)

Contributor

brikou commented Apr 3, 2012

@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

This comment has been minimized.

Show comment
Hide comment
@stof

stof Apr 3, 2012

Contributor

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

Contributor

stof commented Apr 3, 2012

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

This comment has been minimized.

Show comment
Hide comment
@digitalkaoz

digitalkaoz Apr 3, 2012

Contributor

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

Contributor

digitalkaoz commented Apr 3, 2012

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

This comment has been minimized.

Show comment
Hide comment
@stanlemon

stanlemon Apr 8, 2012

Contributor

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

Contributor

stanlemon commented Apr 8, 2012

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

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Apr 8, 2012

@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

ghost commented Apr 8, 2012

@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

This comment has been minimized.

Show comment
Hide comment
@mvriel

mvriel Apr 8, 2012

Contributor

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?

Contributor

mvriel commented Apr 8, 2012

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

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Apr 8, 2012

@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.

ghost commented Apr 8, 2012

@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

This comment has been minimized.

Show comment
Hide comment
@igorw

igorw Apr 8, 2012

Contributor

@mvriel I like that idea a lot!

Contributor

igorw commented Apr 8, 2012

@mvriel I like that idea a lot!

@stanlemon

This comment has been minimized.

Show comment
Hide comment
@stanlemon

stanlemon Apr 8, 2012

Contributor

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.

Contributor

stanlemon commented Apr 8, 2012

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

This comment has been minimized.

Show comment
Hide comment
@stanlemon

stanlemon Apr 8, 2012

Contributor

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.

Contributor

stanlemon commented Apr 8, 2012

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

This comment has been minimized.

Show comment
Hide comment
@Seldaek

Seldaek Apr 10, 2012

Member

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

Member

Seldaek commented Apr 10, 2012

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

@Seldaek

This comment has been minimized.

Show comment
Hide comment
@Seldaek

Seldaek Apr 10, 2012

Member

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.

Member

Seldaek commented Apr 10, 2012

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

This comment has been minimized.

Show comment
Hide comment
@digitalkaoz

digitalkaoz Apr 10, 2012

Contributor

i like the first approach

Contributor

digitalkaoz commented Apr 10, 2012

i like the first approach

@brikou

This comment has been minimized.

Show comment
Hide comment
@brikou

brikou Apr 10, 2012

Contributor

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

Contributor

brikou commented Apr 10, 2012

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

@naderman

This comment has been minimized.

Show comment
Hide comment
@naderman

naderman Apr 10, 2012

Member

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/*"]}]
}
Member

naderman commented Apr 10, 2012

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

This comment has been minimized.

Show comment
Hide comment
@Seldaek

Seldaek Apr 10, 2012

Member

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": []?
Member

Seldaek commented Apr 10, 2012

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

This comment has been minimized.

Show comment
Hide comment
@naderman

naderman Apr 10, 2012

Member
  • 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).
Member

naderman commented Apr 10, 2012

  • 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

This comment has been minimized.

Show comment
Hide comment
@stof

stof Apr 10, 2012

Contributor

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.

Contributor

stof commented Apr 10, 2012

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

This comment has been minimized.

Show comment
Hide comment
@Seldaek

Seldaek Apr 10, 2012

Member

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.

Member

Seldaek commented Apr 10, 2012

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

This comment has been minimized.

Show comment
Hide comment
@naderman

naderman Apr 10, 2012

Member

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.

Member

naderman commented Apr 10, 2012

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

This comment has been minimized.

Show comment
Hide comment
@RobLoach

RobLoach Jun 19, 2012

Contributor

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.

Contributor

RobLoach commented Jun 19, 2012

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

This comment has been minimized.

Show comment
Hide comment
@mneuhaus

mneuhaus Nov 12, 2012

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

mneuhaus commented Nov 12, 2012

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

@RobLoach

This comment has been minimized.

Show comment
Hide comment
@RobLoach

RobLoach Nov 12, 2012

Contributor

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 .

Contributor

RobLoach commented Nov 12, 2012

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

This comment has been minimized.

Show comment
Hide comment
@rawtaz

rawtaz Mar 8, 2013

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!

rawtaz commented Mar 8, 2013

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

This comment has been minimized.

Show comment
Hide comment
@RobLoach

RobLoach Mar 8, 2013

Contributor

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.

Contributor

RobLoach commented Mar 8, 2013

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

This comment has been minimized.

Show comment
Hide comment
@reinier

reinier Mar 14, 2013

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.

reinier commented Mar 14, 2013

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

This comment has been minimized.

Show comment
Hide comment
@mnapoli

mnapoli Mar 14, 2013

@reinier yes, that is what you need.

mnapoli commented Mar 14, 2013

@reinier yes, that is what you need.

@spenat28

This comment has been minimized.

Show comment
Hide comment
@spenat28

spenat28 Mar 14, 2013

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

spenat28 commented Mar 14, 2013

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

@rawtaz

This comment has been minimized.

Show comment
Hide comment
@rawtaz

rawtaz Mar 14, 2013

@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.

rawtaz commented Mar 14, 2013

@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

This comment has been minimized.

Show comment
Hide comment
@mnapoli

mnapoli Mar 14, 2013

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.

mnapoli commented Mar 14, 2013

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

This comment has been minimized.

Show comment
Hide comment
@pscheit

pscheit Aug 23, 2013

Contributor

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

Contributor

pscheit commented Aug 23, 2013

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

@rawtaz

This comment has been minimized.

Show comment
Hide comment
@rawtaz

rawtaz Aug 23, 2013

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 commented Aug 23, 2013

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

This comment has been minimized.

Show comment
Hide comment
@rawtaz

rawtaz Sep 21, 2013

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.

rawtaz commented Sep 21, 2013

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

This comment has been minimized.

Show comment
Hide comment
@CMCDragonkai

CMCDragonkai Nov 16, 2013

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

CMCDragonkai commented Nov 16, 2013

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

@Anahkiasen

This comment has been minimized.

Show comment
Hide comment
@Anahkiasen

Anahkiasen Jan 14, 2014

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.

Anahkiasen commented Jan 14, 2014

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

This comment has been minimized.

Show comment
Hide comment
@pscheit

pscheit Jan 14, 2014

Contributor

put everything on npm! ;)

Contributor

pscheit commented Jan 14, 2014

put everything on npm! ;)

@garak

This comment has been minimized.

Show comment
Hide comment
@garak

garak commented Mar 21, 2014

Something like http://bowephp.org/ ?

@cebe

This comment has been minimized.

Show comment
Hide comment
@cebe

cebe Apr 30, 2014

Contributor

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.

Contributor

cebe commented Apr 30, 2014

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

This comment has been minimized.

Show comment
Hide comment
@Anahkiasen

Anahkiasen Apr 30, 2014

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

Anahkiasen commented Apr 30, 2014

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

@cebe

This comment has been minimized.

Show comment
Hide comment
@cebe

This comment has been minimized.

Show comment
Hide comment
@cebe

cebe Apr 30, 2014

Contributor

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

Contributor

cebe commented Apr 30, 2014

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

@jaylinski

This comment has been minimized.

Show comment
Hide comment
@jaylinski

jaylinski May 19, 2014

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.

jaylinski commented May 19, 2014

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

This comment has been minimized.

Show comment
Hide comment
@alcohol

alcohol Jul 30, 2015

Member

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

Member

alcohol commented Jul 30, 2015

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

@Seldaek

This comment has been minimized.

Show comment
Hide comment
@Seldaek

Seldaek Jul 30, 2015

Member

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

Member

Seldaek commented Jul 30, 2015

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment