Skip to content
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

Closed
RobLoach opened this issue Sep 18, 2012 · 35 comments
Closed

Bower Repository #1121

RobLoach opened this issue Sep 18, 2012 · 35 comments

Comments

@RobLoach
Copy link
Contributor

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.

@Seldaek
Copy link
Member

Seldaek commented Oct 21, 2012

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

@RobLoach
Copy link
Contributor Author

@Seldaek I agree, it's rather awkward to ask these packages to add a composer.json file, but I'm not quite sure of a way around it. package.json files are quite different than a composer.json:

  • The version is sometimes packaged in the package.json file (not the tag)
  • The dependencies refer to node and building packages
  • Grunt.js is used to build a certain package. Some shim repositories have been built to allow installation without needing grunt (that's what I'm taking advantage of here)

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?

@Seldaek
Copy link
Member

Seldaek commented Oct 21, 2012

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.

@RobLoach
Copy link
Contributor Author

JamJS's repository is a bit more standard in how the "built" packages are presented:
http://jamjs.org/packages/#/category/All

The repository is available via CouchDB:
http://jamjs.org/repository/_design/jam-packages/_view/packages_by_category?reduce=false&include_docs=true&limit=500&skip=0

For example, in TableSorter, you can see the build archive has a package folder, and package/package.json instructs where main is:
http://jamjs.org/packages/#/details/tablesorter

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 composer.json directly could do the job. The custom installer also writes a requirejs config for you too, which equates to an autoload.js file, essentially.

Would you suggest we have a repository browser in Composer that reads these packages and writes the require.js config for us?

@RobLoach
Copy link
Contributor Author

RobLoach commented Nov 6, 2012

http://github.com/component has a nice set up.

@adamramadhan
Copy link

i agree with this, we could integrate it somewhere in vendors. maybe vendors/components/ ? just an idea.

@kingcrunch
Copy link
Contributor

Just to push this topic: Anything new regarding this topic?

Sorry, if there is another discussion active.

@RobLoach
Copy link
Contributor Author

RobLoach commented May 1, 2013

@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!
https://packagist.org/search/?type=component

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.

@sstok
Copy link
Contributor

sstok commented May 8, 2013

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
but Bower has no clear way to overwrite the final source to package like composer does making it not always workable..

@andrerom
Copy link
Contributor

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?
Could basically be in your composer.json defined as a command to run on install (and update)? so that following a approach like this would allow external package manager to install assets into the package structure, combined with a require "cmd-*" or similar to define requirement for the command needed this could allow us to combine composer with bower, (..)

@fprochazka
Copy link
Contributor

Can't you just add after update/install script in your project's composer.json? Something like bower update?

@andrerom
Copy link
Contributor

That will only take care of root package, not the installed vendor packages (custom script is only executed in root package).

@buzzedword
Copy link

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 .bowerrc file for additional settings. This is a fully qualified .json file which could either be present at the application root, as it would be if bower were used natively, or included in the configuration for component.json. There's a lot of opportunities here that can allow for unified package management without ever having to hit Node.JS, and allowing framework maintainers to fully control which assets are to be packaged, where they are to be directed, and still have the ability to integrate with a frontend developers normal workflows.

@oscarotero
Copy link

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:

$ composer bower install jquery

This allows build other package managers on top of composer (jam, component, etc)
I don't know if this is possible or hard to build, it's only an idea.

@msumme
Copy link

msumme commented Nov 20, 2013

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.

@andrerom
Copy link
Contributor

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.
Then an external project can take on the challenge of re-implementing bower in php to avoid using node.js on install.

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.

@kingcrunch
Copy link
Contributor

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

@oscarotero
Copy link

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: $ composer self-install bower can extend the composer library with the bower client. Once it's installed, the command "bower" is available: $ composer bower install jquery.

@kingcrunch
Copy link
Contributor

@oscarotero And whats the benefit compared to

bower-php install php

?

Imo the CLI frontend is the smallest issue 😉

@andrerom
Copy link
Contributor

Imo the CLI frontend is the smallest issue 😉

yep, lets not decide on the color of the bike-shed just yet ;)

@oscarotero
Copy link

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

@kingcrunch
Copy link
Contributor

@oscarotero As implied above: A simple ScriptHandler could just call bower-php install when needed. On the other hand I see no reason why composer should care about downloading, extracting and such.

But maybe creating a plugin system to composer can complicate things and a independent bower client in php is better. I don't know.

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.

@oscarotero
Copy link

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

@rvanlaak
Copy link

Using the post-install-cmd and post-update-cmd can resolve this topic. Just add a bower.json file to your project. It could be as simple as showcased in the following Gist:
https://gist.github.com/daFish/4065648

or

 "scripts": {
    "post-install-cmd": [
        "bower install"
    ],
    "post-update-cmd": [
        "bower install"
    ]
}

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 bower resolved?

@andrerom
Copy link
Contributor

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 )

@cebe
Copy link
Contributor

cebe commented Apr 2, 2014

Citing a comment of me in an other issue:

Composer already has the possiblility to install packages from the pear library. It should be
possible to allow composer to install packages from package sources like bower too if some
installers for that are added, maybe based on bowerphp.

maybe this helps to find a solution for this issue.

@PowerKiKi
Copy link

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.

@francoispluchino
Copy link
Contributor

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

  1. distinguish the name of a package Composer with a package Bower
  2. create a BowerRepository to retrieve packages and versions from the Bower API
  3. create a BowerPackage used by BowerRepository
  4. use the native Downloaders of Composer

As regards the constraint 1, we could solve this by prefixing the package name by bower:, ex. "bower:<package>": "<version>". Would have BowerRepository detects the prefix and removes it automatically (check that it is feasible).

As regards the constraint 2, Is that a plugin can register a new repository in her activate method? At first sight, I think so, but we must check that the LocalRepository is not blocked before recording plugin.

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 composer.json file, and it will rescan for dependencies on the new repository Bower.

@Seldaek Is it possible to add new repository from a plugin? Plugins added in require of a project are they installed before the other dependencies? [And in this case, is that the plugin is automatically registered before checking dependencies of the project?]

@Seldaek
Copy link
Member

Seldaek commented Jun 3, 2014

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.

@cebe
Copy link
Contributor

cebe commented Jun 29, 2014

Currently working on a proof of concept for this: https://github.com/cebe/composer-bower
It is already working partially. Implementation has to be completed but it looks promising.

@francoispluchino
Copy link
Contributor

@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 package.json for NPM and bower.json for Bower, through the automatic creation of VCS Repository.

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.

@mgol
Copy link

mgol commented Aug 2, 2015

FWIW, jQuery has been published to npm since 1.11/2.1; it's a regular jQuery, without any Node-specific wrapping.

@Seldaek
Copy link
Member

Seldaek commented Feb 21, 2016

Closing as it's very unlikely and not sure it's desirable tbh.

@Seldaek Seldaek closed this as completed Feb 21, 2016
@lkraav
Copy link

lkraav commented Feb 21, 2016

PS in the JS ecosystem, numerous arguments have lately been made towards dropping bower in favor of npm.

necolas/normalize.css#455
https://gofore.com/stop-using-bower/

etc. For more, google the relevant keywords and notice pull requests all around.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests