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

[WIP] Bower package manager / non-PHP dependencies #3209

Closed
wants to merge 16 commits into from

Conversation

pmoust
Copy link
Contributor

@pmoust pmoust commented Apr 21, 2014

Relates; #2965 #3196

@pmoust
Copy link
Contributor Author

pmoust commented Apr 21, 2014

Re-submitted the PR due to forked repo branch being deleted in the past.

@pmoust
Copy link
Contributor Author

pmoust commented Apr 21, 2014

Travis break has to do with Bee-Lab/bowerphp#36 I 'll submit a PR there if the maintainer is too busy.
(jquery-ui requires jquery>=1.6 in its bower.json, which currently bowerphp fails to interpret.

@DrMabuse23
Copy link

nice

@cebe cebe added this to the 2.0 RC milestone Apr 21, 2014
This reverts commit d58c2c6.
Bowerphp resolved the issue with Github API pagination and added proper
version tagging
@pmoust
Copy link
Contributor Author

pmoust commented Apr 22, 2014

Should be fine now, maintainer fixed the pagination issue with Github API and has added proper release tags.

@basil-inc
Copy link
Contributor

Thumbs up for adding bower support out-of-the-box!

@samdark
Copy link
Member

samdark commented Apr 24, 2014

pros

  • Provides a way to install/manage large variety of JS packages (Composer doesn't manage JS packages generally).
  • Allows Yii not to maintain own Composer JS packages.
  • Since it doesn't add any non-php dependencies it doesn't make framework entry level any higher.

cons

  • Two dependency configs insead of one. Complicates things a bit.

@cebe
Copy link
Member

cebe commented Apr 24, 2014

I am still thinking that this is something composer should implement as it is the case with pear packages for example.

What about the following situation:

I have a yii extension that requires jquery > 2.0. how would I define that and does dependency resolving work properly?

@pmoust
Copy link
Contributor Author

pmoust commented Apr 24, 2014

@cebe
Copy link
Member

cebe commented Apr 24, 2014

that may be a workaround but in the first place I'd expect bower to complain about conflicting requirements when the app requires a different version that the extension.

Can you explain how I can add bower.json to an extension? When installing the extension, ist it enough to require it in composer.json or do I need more?

@pmoust
Copy link
Contributor Author

pmoust commented Apr 24, 2014

Sorry, I misread your comment @cebe.
A yii extension requiring a specific version of jquery would define that version in its bower.json I suppose and be declared at a class extending AssetBundle. I don't see the problem here.

I would argue it is much better than packing the JS/CSS/Whatever within the yii extension itself.

@cebe
Copy link
Member

cebe commented Apr 24, 2014

I would argue it is much better than packing the JS/CSS/Whatever within the yii extension itself.

Don't get me wrong, I am for changing the current situation. But I am not sure if this solution really works. At least I did not fully understand the idea here and it looks to me there is something missing.

@pmoust
Copy link
Contributor Author

pmoust commented Apr 24, 2014

  1. There should not be a need to add it in composer.json, just bower.json, however if bowerphp is to be used from within composer like the hooks I have added to ease the curve as @samdark pointed out, then this extension might want to include such hooks as well. I am against it in general though.
  2. An extension requiring a specific version would be best to declare the install directory within bower.json as illustrated on the StackOverflow link I pasted above, and link the assets to that one instead of overwriting others. For instance I would instruct a custom JUI-pmoust extension using jquery-ui vX.Y.Z to keep that package to @bower/jquery-ui-pmoust and keep that reference in the code itself.
    Sorry if I am not making it very clear.

@cebe
Copy link
Member

cebe commented Apr 24, 2014

  1. if my extension contains JS and PHP code, it has to be in composer.json as far as I see. Otherwise there would be no chance to autoload classes.
  2. the problem here is that you can not run two versions of jquery on the same site without aliasing them. Also if the application requires the right version that is perfectly fine, I do not need an alternative version to be installed then. The case I am talking about is when versions are conflicting the package manager should warn about that and prevent installation.

As far as I see this problem can be solved better as a composer extension. Will try to check this option tomorrow. Thanks for your input so far!

@DrMabuse23
Copy link

and how did you wann handle this ??

[scss]
@import
"bourbon",
"neat",
"neat-helpers",
"bitters/variables",
"bitters/typography",
"bitters/bitters",
"base",
"menu",
"logo",
"hover_tile",
"animate"
;

bourbon neat bitters are bower packages

@pmoust
Copy link
Contributor Author

pmoust commented Apr 24, 2014

@cebe The yii extension will be added in composer.json of the project. The Bower assets of that extension are added to the bower.json of said extension, just like the PHP dependencies of said extension are added in the extension's composer.json.
I will get back to you with a definite answer about a version conflict if my previous answer does not cover you.

@cebe
Copy link
Member

cebe commented Apr 24, 2014

@brewing can you please elaborate a bit more about what problem you are describing?

@DrMabuse23
Copy link

@cebe i mean how to handle scss files because '@bower ' still not exist in scss files.

@cebe
Copy link
Member

cebe commented Apr 24, 2014

'@bower ' still not exist in scss files.

what does that mean?

@DrMabuse23
Copy link

the alias are not exist

For instance I would instruct a custom JUI-pmoust extension using jquery-ui vX.Y.Z to keep that package to @bower/jquery-ui-pmoust and keep that reference in the code itself.

@DrMabuse23
Copy link

well for js files i think this will still work

@qiangxue
Copy link
Member

@pmoust Assuming we take this PR and we are building an application which needs to use yii2-jui, what do we need to do in order to install and use yii2-jui?

@pmoust
Copy link
Contributor Author

pmoust commented Apr 24, 2014

@qiangxue should be just adding yii2-jui into composer.json and installing it. I 'll mark this PR as [WIP] so I can integrate Bower support a tad better by the yii2-composer extension so there is a seamless integration with Bower without needing nodejs/npm/bower but just bowerphp to work.
It will be a global solution for all yii2-extensions. Directly using npm/bower will be strictly optional.

@cebe I am marking it WIP and will ping you to review when it is done.

@pmoust pmoust changed the title Bower package manager / non-PHP dependencies [WIP] Bower package manager / non-PHP dependencies Apr 24, 2014
@qiangxue
Copy link
Member

Could you create a new PR which handlesyii2-composer and jquery only? Currently this PR about jui is too big to be easily reviewed.

@tonydspaniard
Copy link
Contributor

Sorry to all, but even though I do believe is a good thing to have bower support, I have to admit (upon usage), that bower installations are not sync with composer installs and that causes our projects to be populated with folders such as:

  • bower_components
  • vendor (composer with some js installs)
  • components (some javascript packages install vendor refs on this folder instead in bower_components folder.

And tones of repetitive files (lots of scripts do have the js installed through composer). So, a developer has to be very careful not to end up with lots of repetitive scripts everywhere. BowerPHP is a great source, I used in some of my projects but a developer must be very, very careful. I don't think is good for a general purposes and it just suits certain scenarios.

@kartik-v
Copy link
Contributor

kartik-v commented May 2, 2014

Trying to look at the end design and pre-requisites to achieve that. Are we achieving somehow bower and composer to work together like this:

  1. bower manages all JS and CSS packages and dependencies
  2. composer manages all PHP dependencies.

Assuming above is true and all dependencies between PHP code and required JS/CSS work magically --- following is needed

We would also need to be kind of forcing a standard in building all extensions.

  • Extensions must use bower ONLY for maintaining all CSS & JS code.
  • Extensions must use composer ONLY for maintaining all PHP code.

If both are not adhered strictly - we may fall into issues. Am I right in framing this target design specification?

BTW - @pmoust great work so far.

@cebe cebe self-assigned this Jun 4, 2014
@creocoder
Copy link
Contributor

@pmoust Any news on it? Does that mean we will use famous bower instead of doubtful asset bundles approach? If so, than GREAT WORK! 👍

@creocoder
Copy link
Contributor

Btw why bowerphp instead of original bower??? Vote against it.

@samdark
Copy link
Member

samdark commented Jun 16, 2014

@creocoder no, it's about getting JS/CSS files, not about serving or compressing these via asset bundles. Also phpbower allows you to use it right away while bower requires nodejs to be installed along with bower.

@pmoust
Copy link
Contributor Author

pmoust commented Jun 16, 2014

@creocoder I 'll work on it during this weekend. I' ll choose whether closing this down in favor of a cleaner way to do things, or improve the current PR and request for review.

As @samdark mentioned, the only reason we go with bowerphp vs bower is to reduce the dependencies for developers and/or deploying mechanisms.

@creocoder
Copy link
Contributor

@samdark @pmoust I thinks we need to go with original bower with possibility to switch to bowerphp as alternative. I do not see any relation from bowerphp to original bower creators. Also it have only 100 github stars. Trust bowerphp for now is BIG mistake.

@samdark
Copy link
Member

samdark commented Jun 16, 2014

@creocoder it will make Yii dependent on nodejs. We can't afford it.

@creocoder
Copy link
Contributor

@samdark Then i vote against about bower at all. Or original bower, or composer (we can live with that). We can't trust bowerphp at all. This is not official bower.

@DrMabuse23
Copy link

this make no sense to use bower over php !!!

@samdark
Copy link
Member

samdark commented Jun 16, 2014

The thing is that we cannot force requirement on nodejs, npm and bower since it will raise overall framework complexity significantly enough to lose very big part of the community.

@samdark
Copy link
Member

samdark commented Jun 16, 2014

Discussed a lot with @creocoder, got the following cons/pros and decided to leave everything as is + create a guide to using bower with Yii2 (not sure if it will be in official docs or Yii cookbook yet): https://docs.google.com/document/d/1PttOYSBHj6xuE4-iaOcUYLj0Ly5lLjANitNOZTaB2l8

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

Successfully merging this pull request may close these issues.

9 participants