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
Bower Repository #1121
Comments
@RobLoach it's good that you're trying stuff, but I don't think a custom installer is the right direction - because that still requires those repos to support composer, which is a no-go. |
@Seldaek I agree, it's rather awkward to ask these packages to add a
Unsure how Composer can index all that properly when there's so much variation in how each package is sourced. Did you have any ideas? |
I still think the best way would be to read a centralized repo (be it npmjs or something else) of JS packages. Bower has a repo but last time I checked it was kind of manually maintained and not quite exhaustive. npmjs isn't ideal either because it has for example jquery packages that are hacked versions to run in the node environment and not the browser, therefore confusion could ensue. |
JamJS's repository is a bit more standard in how the "built" packages are presented: The repository is available via CouchDB: For example, in TableSorter, you can see the build archive has a Most of the built packages with Jam are in this format, it seems. Even still, it seems rather complicated to go through these hoops when a custom installer indexing packages with Would you suggest we have a repository browser in Composer that reads these packages and writes the require.js config for us? |
http://github.com/component has a nice set up. |
i agree with this, we could integrate it somewhere in vendors. maybe vendors/components/ ? just an idea. |
Just to push this topic: Anything new regarding this topic? Sorry, if there is another discussion active. |
@kingcrunch I've pushed Composer support to a few of the packages on http://github.com/components , which are shared with Bower. It also mirrors some of the JavaScript loader functionality present in many of the other front-end package manager systems out there. Would love your input, and some of your thoughts on where it could go. Thanks a lot! It's true that it isn't indexing the Bower/npm repository, but those operate much differently than how Composer functions. Dependencies are handled differently, the main directive is different. Bower is Bower, npm is npm, Composer is Composer. Indexing another repository would be neat, but this is working, and is complete with built dependencies. |
When installing the components I would like to configure a directory as vendor/components is not accessible by assetic. And making symlinks is hell on Windows 💩 I actually found this bundle (https://github.com/Spea/SpBowerBundle) today |
Ended up on this thread in search for a solution to 1. avoid having to keep external assets in our repo and 2. not having to run both composer, and then bower for each and every composer package that needs it. What if composer gained a sub-package-manager feature? |
Can't you just add after update/install script in your project's |
That will only take care of root package, not the installed vendor packages (custom script is only executed in root package). |
Bumping this up. If there's any additional interest in doing this, I highly recommend using Bower. Bower's pretty much one of the de-facto standards in the Frontend world. Jam and Component are still around, but when you look at what Yeoman is using (Yeoman being the big brother to Grunt, one of the most popular frontend tooling solutions) for dependency management, you'll see it's powered by Bower. Furthermore, Bower's spec is significantly more fleshed out than Component, and also has a repository API available as detailed here. Although Component uses Github as a repository, the ability to add packages is limited to a select few-- treating it less of a Packagist and more of a curated list. The only additional input I would give here is that if you also look at the Bower spec you'll note a configuration section, in which bower honors a |
I think it would be awesome if composer could support bower, because there are many hosting services without node installed (or not the latest version) and install/upgrade is not allowed. I don't think force bower packages to work in composer way is a good idea, maybe creating a bower client in php, taking advantage of all good stuff created to composer, but with the bower api, is better to have the best of both worlds. For example:
This allows build other package managers on top of composer (jam, component, etc) |
This is an excellent idea. It's generally recommended not to embed CSS/JS frameworks in your PHP composer packages, but there is little to no support for adding those dependencies to your composer projects in a logical / best-practices way. Composer is for PHP, but creating a modern web application requires a lot of front-end work. Adoption of Composer/Symfony ecosystem would soar if front-end library support was first-class. If you could manage dependencies between your javascript and eventually Sass/CSS frameworks and know you're doing it right, you'd see a lot less head-scratching, and a lot more amazing web applications with rich front-ends being built on Symfony/composer. Composer is an amazing tool, and making it easy to integrate with related dependency managers is a wise idea. If Bower already has widespread adoption and is the de-facto standard, a PHP port would be great for just the reasons @oscarotero mentioned, although it would be better if PHP projects could also define their JS dependencies so that when we do an update, we can make sure our front-end frameworks are in sync with our server code wherever necessary. If composer adopted bower as the standard, it might be possible to simply resolve bower dependencies, then resolve composer dependencies, and only if those all work do we update the project. Javascript dependencies are just as complex, maybe more, as PHP dependencies. If we could support that in our PHP libraries with front-end components, it would be really beautiful. |
I don't think it is composers task to re implement bower, this would limit the reach of this feature. I rather think there is a need for general pre processor support that should be executed on install / update. Other use cases: Your code takes advantage of HHVM language features not available in Zend engine based PHP, preprocessor would then be a good way to filter/adapt the use on install. |
@andrerom 👍 Bower-client as separate applications probably makes more sense. It should be possible to let composer interact with that application with common post-update/post-install scripts. |
I'm agree that a bower client must be a separate project (outside composer core) but I think that composer should be extensible with this kinds of plugins. Something like: |
@oscarotero And whats the benefit compared to
? Imo the CLI frontend is the smallest issue 😉 |
yep, lets not decide on the color of the bike-shed just yet ;) |
@kingcrunch The benefit is that the plugin can use the composer library to clone repositories, download and extract zip files, send messages to cli, etc, or even configure events, for example update bower just after update composer, etc, I mean not reinvent the wheel. But maybe creating a plugin system to composer can complicate things and a independent bower client in php is better. I don't know. |
@oscarotero As implied above: A simple ScriptHandler could just call
My words 😄 But then I don't know, how it gives me a benefit, when it is reintegrated into composer again 😕 Let composer trigger something (via script) is something different, but let composer redirect commands there, I see no use. |
@kingcrunch Ok. I see your point. A bower php client is not different to other php cli based utilities such phpunit, database migrations, etc. So the best is to install it like any other package and use it when needed. |
Using the or
But, this does not address the "problem" where applications can have fixed dependencies on frontend libraries. In other words; should it be possible for composer to make decisions based on the dependencies that |
This thread is rather to allow a package to specify it needs with another package manager like bower, so the package isn't the root project, and hence it's commands won't be executed. That being said, I guess the use case here can be accomplished as a composer plugin now, if that is the case this issue can be closed. (ping @Seldaek ) |
Citing a comment of me in an other issue:
maybe this helps to find a solution for this issue. |
The huge advantage I can see in first-class support of Bower within Composer itself would be to benefit from Composer's dependencies resolution algorithm, and the lock file concept. Bower is still missing the concept of "locking" all dependencies, and while there is an active discussion on the topic (bower/bower#505), I don't see it solved any time soon. So if integrating Bower into Composer would allow us to benefit from the well-tested lock system that use Composer, and use only a single tool to manage all dependencies, that would be great. |
@oscarotero Currently it is not possible to add a custom command to Composer with a plugin (see #1234), but I think it would be interesting to manage dependencies with Composer system. Create a plugin to use the native features of Composer for manage Bower dependencies would be relevant. @cebe To do this, we must solve several constraints:
As regards the constraint 1, we could solve this by prefixing the package name by As regards the constraint 2, Is that a plugin can register a new repository in her Another problem, the Composer plugin must be installed before running the install/update commands. But perhaps it is possible to include the plugin in the project root @Seldaek Is it possible to add new repository from a plugin? Plugins added in |
Nope with the current setup it's not possible. But then again it seems some people see bower as a bad thing and say that using npm + browserify for frontend packages is a better idea, which I can agree with since bower is kind of an incomplete copy of npm. |
Currently working on a proof of concept for this: https://github.com/cebe/composer-bower |
@cebe I think it is better to go through the plugin system and not create a new CLI application. It is for this reason that I created a plugin for accessing to files Currently the plugin only works in global mode, but there is a PR #3082 waiting, for restart the installation after installing plugins, and in this case, the plugin can be added directly to the project dependencies. Still I have to finish testing, and I added the creation of VCS Repository for dependencies to a URL (bower), as well as add some missing conversion of version between NPM/Composer and Bower/Composer (ex. X.X.Xpre). If someone is interested, I can work in this direction, and all comments would be interesting. |
FWIW, jQuery has been published to npm since 1.11/2.1; it's a regular jQuery, without any Node-specific wrapping. |
Closing as it's very unlikely and not sure it's desirable tbh. |
PS in the JS ecosystem, numerous arguments have lately been made towards dropping necolas/normalize.css#455 etc. For more, google the relevant keywords and notice pull requests all around. |
Bower is a package management system for JavaScript and CSS assets. A list of Bower packages is available here: http://sindresorhus.com/bower-components/ . The source and repositories for these packages is fed from here: http://bower.herokuapp.com/packages
JamJS is another package management system for web assets. Worth mentioning.
Leveraging these repositories from Composer would expose a huge amount of new packages to be consumed.
The text was updated successfully, but these errors were encountered: