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

Already on GitHub? Sign in to your account

Created asset installer, unit tests and updated documentation #545

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
9 participants
Contributor

mvriel commented Apr 8, 2012

Added a new type 'asset' with which you can define a specific location (relative to the composer.json) instead of the vendor-dir+package-name.

Possible vector with which to solve #524.

By adding an element asset-dir in the extra section of the package definition will the package install itself to a different location. This can be used to, for example, package twitter bootstrap and have it install onto a specific folder (such as /web).

Included in this PR is the source, an update to the documentation and a unit test.

Owner

naderman commented Apr 8, 2012

But this would mean that packages can contain only assets or only non-assets, but never both? Do we really want that?

Contributor

mvriel commented Apr 8, 2012

That is a good question. The way I perceive it is that libraries are always installed into the vendor folder and if they contain assets then the user is responsible for symlinking to them (perhaps via a script).

But if you have a package that combines assets and library files then you probably would not want them in your vendor folder (Symfony2 bundles are a good example). In which case the AssetInstaller can help you out there.

(perhaps the name AssetInstaller is unfortunate?)

I wonder if you should want to mix library and asset files in one package; because in that case I'd think you'd need to be able to define a 'root folder' per directory in the package?

Owner

Seldaek commented Apr 8, 2012

@mvriel Symfony bundles are installed in vendor too, but symfony comes with the assets:install command that copies them (or symlinks) out of the bundles' public/ dir into the web/ directory.

Anyway as I've said already in other related issues, I would like to have a good concept before doing anything in this regard, because if we move too fast we'll blow it, and I don't want to get stuck with a poor solution forever. This is not an ideal solution IMO because the packages themselves define where they go, while every framework has its own conventions as to where assets should go.

If it would read the "asset-dir" from the main package (i.e. the root composer.json), this would be better already, but even then I'm not sure if it's sufficient, because I'm sure some projects want css files in some dir, js in another, etc.

Contributor

benja-M-1 commented Apr 9, 2012

What about using the config property "vendor-dir" when you require something that have to be in another directory than vendor like assets?

For instance with twitter/boostrap we could have this repository configuration:

"repositories": [
        {
            "type": "package",
            "package": {
                "version": "master",
                "name": "twitter/bootstrap",
                "source": {
                    "url": "https://github.com/twitter/bootstrap.git",
                    "type": "git",
                    "reference": "master"
                },
                "dist": {
                    "url": "https://github.com/twitter/bootstrap/zipball/master",
                    "type": "zip"
                },
                "config": {
                    "vendor-dir": "web"
                }
            }
        }
]

I tried this but without success, twitter/boostrap is uploaded into the "vendor" directory instead of "web". This could be a simpler solution?

Owner

naderman commented Apr 9, 2012

Configuration options are not available for remote packages. They can only be set in the main package. The vendor-dir option is not a per-package option, but a global setting for all your dependencies.

Instead packages can provide additional metadata through the extra key. What's being discussed above however, is whether or not we would even want to only move entire packages into an assets directory, or maybe just some directories inside of them. And we would probably like to configure the location in one place, and not for each package. Particularly packages should have no influence over where in my project I would like to install assets. E.g. if I want to call my web directory "public", then bootstrap should certainly not be installed into "web".

@Seldaek Seldaek referenced this pull request Apr 10, 2012

Closed

Custom asset paths #557

Contributor

RobLoach commented Jun 19, 2012

Also note that "repositories" won't work on parent projects as it's not a recursive property.

Would be neat if there was some project that would read through the "extra" key, and would instruct Assetic to perform Grunt-like operations on the assets.

Contributor

RobLoach commented Oct 21, 2012

I think as well, that frameworks should handle the task of copying/symlinking the assets to the right location.
Maybe the only thing a package should be able to describe, and is which path contains possible assets.

I really hope that's this will be possible at some point, because currently it's quite a mess to have those 'unmanaged' assets cluttering up packages that sometimes contain static versions common assets over and over again.

I'm trying to figure this out with a custom installer and reading several issues related but a little confused by them. What about simply adding multiple objects to the main composer.json file in my project like the following? Is this possible? I can't really tell by the documentation if it is possible to have both a regular composer.json and a custom composer.json.

This is the base where all packages are php and should go in the default vendor directory

{
    "require": {
        "illuminate/foundation": "1.2.*",
        "meido/html": "1.0.*",
        "meido/form": "1.0.*",
        "meido/str": "1.0.*",
        "zend/acl": "dev-master"
    },
    "autoload": {
        "classmap": [
            "app/controllers",
            "app/models",
            "app/database/migrations",
            "app/tests/TestCase.php"
        ]
    },

    "minimum-stability": "dev",

}   


I want to add something like the following to the main root composer.json (this same file) rather than
having to have multiple composer.json

{
    "type": "public-asset",

    "require": {
        "twitter/bootstrap": "dev-master"
    },

    "extra": {
        "class": "Vendor\\Composer\\Libs\\PublicAssetInstaller"
    }
}

Sorry if I misunderstand, is the custom installer intended for vendors to use rather than for the developer to use like I'm trying to use it above? I see in phpdocumentor they made the installer for their unified-asset-installer. I suppose if the above is not possible, rather than relying on various vendors to make a custom installer I could fork them and add to my own private composer repo?

Nevermind, I got it figured out. It just took a while to figure out I had to make and install the custom installer and then modify the vendor package to add the type and require. I wasn't sure where exactly everything was supposed to go but got it worked out. https://github.com/isimmons2/laravel4-public-asset-installer

It will definitely be nice if it is possible later to just specify the directories in the main composer.json file but this works for now.

Thanks

Baachi commented Jan 21, 2013

I don't think its useful to install assets about composer. Any frontend developer will never use composer for this job, he will use bower, http://yeoman.io or something else. Why reinvent the wheel?

Contributor

RobLoach commented Feb 24, 2013

Alongside Bower and Yeoman, there's also Component too. http://component.io

As for doing this in Composer, I'm all for not re-inventing the wheel and taking advantage of other awesome open source projects, but this is mostly brainstorming. I don't think using a Composer type of "public-asset" is the way to go, because any Composer package type could provide assets. A PHP library, for example, might output some HTML that depends on some CSS to be present in order to work properly.

A few things I'd like to see:

  1. Copy/symlink all files (images, etc) to the web directory
    • Retain the directory structure
    • web/seldaek/awesomejqueryplugin/images/thumbsup.png
  2. Aggregate all scripts to one file
    • Through a CommonJS/RequireJS configuration so load is still fast
    • web/autoload.js
  3. Aggregate all styles to one file
    • Possibly use Assetic to aggregate so that url() links are translated okay
    • web/autoload.css
{
    "name": "seldaek/awesomejqueryplugin",
    "description": "Awesome jQuery Plugin",
    "keywords": ["jquery"],
    "require": {
        "component/jquery": ">=1.7.0"
    },
    "component": {
        "files": [
            "images/thumbsup.png"
        ],
        "styles": [
            "css/awesomejquerystuff.css"
        ],
        "scripts": [
            "js/awesomejquerystuff.js"
        ]
    }
}

Would be nice to index from http://github.com/component as they use the most similar package structure to us (package versions as tags). Would require a repository indexer, similar to how PEAR is done. Possibly just read that "files", "styles" and "scripts" information from the component.json file directly.

@mvriel mvriel closed this Nov 21, 2014

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