create-bundle
create-bundle copied to clipboard
symfony-cmf
Use bower to install deps
It may be a good idea to use the SpBowerBundle to manage dependencies. Create.js is already declared in bower repositories, so we could use it to avoid using submodules.
We were talking about it with @dbu on hackday, this would be one of possible solutions. We have not tested anything though.
The Bower packaging of VIE doesn't probably work correctly yet. Somebody had registered it with wrong repo URL and the compiled version isn't there anyway
@bergie do we need a correct VIE bower, given that the createjs repository includes the vie javascript and other deps directly?
is bower the "composer for javascript"? if it is, we should see with @Seldaek if composer could somehow support bower manifests and fully integrate bower to manage javascript dependencies.
@simensen just pointed out https://github.com/RobLoach/component-installer
seems a bit fresh, IMHO it would be better to use something widely adopted
Yes, it is still a bit fresh. I think it can optionally use other tools behind the scenes but I haven't played with it enough to know how easy it woud be to work with bowser. At the very least, it might have some useful ideas and provide a starting point for a bower-installer for Composer. I'm sure @RobLoach would be happy to talk about other ideas. :)
we would need to find a way to not require the user to install some node.js components imho. if i got the sd bower bundle correctly, it needs to run js on your machine. if we could combine component-installer with the features of the bower bundle (like assetic instead of require js) i think this really would have great potential. maybe jordi could even integrate the component-installer into composer directly?
@bergie The Bower packaging of VIE doesn't probably work correctly yet. Somebody had registered it with wrong repo URL and the compiled version isn't there anyway.
I believe it's missing Vie's dependency on http://github.com/mikeal/request/ . I could be wrong though.
@dbu is bower the "composer for javascript"?
There are many package management systems for JavaScript: npm, bower, component, Jam, volo, Ender to name a few. Each of them does something different and unique. There's a good comparison of some of them over here.
@dbu if it is, we should see with @Seldaek if composer could somehow support bower manifests and fully integrate bower to manage javascript dependencies.
Having Composer index package.json or component.json is something I was thinking about a while ago, but ran into a couple issues:
- There are some deviations between how the manifest files operate and what package management system the package targets. Do we read package.json, or component.json? Is it Bower's component.json, or Component's component.json?
- Indexing/downloading is one thing, installing/compiling is another. Just like how Composer writes an autoload.php, there needs to be a require definition written for us.
I'm not saying it would be impossible though, I just saw a few issues with it. This is why I started work on Component Installer, which means to take the best from npm/bower/component/jam/volo/ender/etc, and use Composer as a base.
@marekkalnik seems a bit fresh, IMHO it would be better to use something widely adopted
Yes, it is still young. There won't be a 1.0 release until it accommodates most of our needs. Would love to have more use cases, and work together on a solution for everyone that uses Composer. I've been working with some of the Bower folk to ensure Component Installer covers Bower's features. Are there any particular features you think it should have?
@dbu we would need to find a way to not require the user to install some node.js components imho. if i got the sd bower bundle correctly, it needs to run js on your machine.
Agreed, keeping the dependencies low is key. Some systems might have node available, others won't.
@dbu if we could combine component-installer with the features of the bower bundle (like assetic instead of require js) i think this really would have great potential.
Although the RequireJS file is written for you, you're not forced to use it. You can still use the single JavaScript/CSS files as usual. A ComponentInstallerBundle is an interesting idea, would love to talk more about this. Where do you see it going?
@RobLoach for me, the most important feature is to handle bower/other managers files. It should be transparent from the package maintainer point of view, because we just can't require people to add another package file.
I don't think a require loader is necessary though. Would be good to have something simple so anyone can use it as he wants later. Something that will just download a library with all required dependencies.
@RobLoach what is the state of the component-installer these days? could it be ready to use? create.js just switched to use bower and we could profit from something reading the bower information...
@dbu Component Installer is doing well. There's a few discussions going on to port it over to use Composer's newly added Composer Plugin class to help clean up the implementation.
We'll have to introduce Composer support to Create.js' dependencies, but once that's done, having direct Create.js build support from Composer would be an easy one to handle. Looks like we'd need Composer support for:
- [x] jquery
- [x] jquery-ui
- [ ] view/VIE
- [x] backbone
- [x] underscore
- [ ] jquery.tagsinput
- [x] annotate
- [x] hallo
making it a composer plugin sounds like the natural thing to do yes. if you code it properly, should be easy to build both a stand alone tool and a plugin also, if there are use cases for the standalone.
can't component installer read bower files to know what to install? bergie showed me that all of them support bower.
@RobLoach btw, i did not mean the above comment to sound negative, i am very grateful that you tackle this topic.
a question about the all.js topic btw: a cmf project could want to always load jquery but only load create.js and its dependencies when the user is allowed to edit. is there a way to control what goes into all.js or do different groups?
@Seldaek wdyt about this approach?
Not sure, sorry but I don't have time to dive into the whole discussion right now. It sounds fine though.
@dbu btw, i did not mean the above comment to sound negative
Didn't sound negative at all, and these are all questions that I've pondered myself.
can't component installer read bower files to know what to install? bergie showed me that all of them support bower.
Many of the shim Bower packages actually share the same repository as Composer. jQuery UI and annotate to name a couple. There are more available at http://github.com/components . These also work against component too, which is equally an awesome package manager.
There could be two solutions around this problem:
- Create a Repository builder that would create a Satis repository from the Bower repository. It would download the Bower index of repositories, and scan through each one, downloading their bower.json, reading the meta-information from each one, creating each version manually, read in the dependencies and map them correctly, and then exposing that in a Satis repository. Doing so would allow you to add the repository to your
"repositories"key, and add the packages to your composer.json accordingly. Had some hacking on this over at bowersatis. - Building native Composer support directly into the packages themselves.
I opted for method two because of the benefits Composer and Packagist bring, and the fact that the work outlined in method 1 is already done when a simple composer.json is present. I'm not opposed to the idea, just seemed like Seldaek and naderman had already done most of the hard-thinking around it. Composer also brings many side-benefits over Bower too, surprisingly, which I've been looking to outline in Front-End Package Manager Comparision. Did you see another solution around indexing bower.json?
a question about the all.js topic btw: a cmf project could want to always load jquery but only load create.js and its dependencies when the user is allowed to edit. is there a way to control what goes into all.js or do different groups?
This is where Require.js/UMD/AMD/etc comes in. Think of require.js like Composer's ClassLoader. You could use Composer without the class loader, but that would need to load all the classes yourself, it would be a lot of unneeded heavy-lifting. Composer's ClassLoader loads only what you want it to load, and the class dependencies from there. Require.js does the same, it'll load only what you want it to load, and figure out the dependencies for you.
There's nothing stopping a customized all.js from happening though. Let's talk about that in the other issue :+1: .
we did this for the TreeBrowserBundle - consequently we should also do it here at some point: https://github.com/symfony-cmf/TreeBrowserBundle/issues/81
maybe keep the composer handlers as alternative