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 package manager instead of Packagist for jQuery #2965

Closed
wants to merge 11 commits into from

Conversation

@pmoust
Copy link
Contributor

pmoust commented Apr 2, 2014

Relates to #2946

After issuing composer commands, Bower is now called to fetch jquery by invoking bowerphp

pmoust added 2 commits Apr 2, 2014
jQuery is package is now fetched from Bower via bowerphp and loaded from
bower_components directory.
post-scripts are now in place to perform bower update/install after
relevant composer command is issued.
@pmoust
Copy link
Contributor Author

pmoust commented Apr 2, 2014

travis failed due to improper location of jquery asset, it has been fixed in 6d48bb4
for some reason it did not re-run

@cebe
Copy link
Member

cebe commented Apr 2, 2014

it will re-run the test. travis is just a bit slow these days.

@cebe
Copy link
Member

cebe commented Apr 2, 2014

What if there is a js package that requires a specific yii version, does it install yii two times then?

@pmoust
Copy link
Contributor Author

pmoust commented Apr 2, 2014

I am not sure what you mean exactly there, composer is something separate from bower. Composer behavior is not changed in this PR (except that it calls bower install/update automatically after such action).

@cebe
Copy link
Member

cebe commented Apr 2, 2014

The problem here is that what I already said in #2946 (comment) it is not good to mix these worlds.
How would a yii extension specify a requirement of a specific jquery version?
How can a js package depend on a specific yii version?
As far as I see the proposed solutions do not work and this has to be adressed on composer level.

@pmoust
Copy link
Contributor Author

pmoust commented Apr 2, 2014

@cebe you bring up a valid point, it should discussed at composer level as well.

However what happens if two extensions require different versions of jquery, how would this be handled?

It is wise to require a specific version application-wise imho.

Btw, I added a proper @bower alias, and proper methods for the configuration. Also added it in the tests and advanced application template. Could you re-run travis?

@pmoust
Copy link
Contributor Author

pmoust commented Apr 2, 2014

I don't know if it is helpful or not, but perhaps we could instruct bower to use vendor dir like composer to avoid adding another alias. Bower supports pointing to an install directory as well by adding to bypass the default bower_components

{
  "directory": "vendor"
}
@qiangxue
Copy link
Member

qiangxue commented Apr 2, 2014

@pmoust I don't want to waste your time, but as explained in #2946 (comment), we are not going to use bower to manage jquery dependency. It just creates unnecessary complexity (the extra bower installation, the new @bower alias, and the dependency problem between two worlds.)

@pmoust
Copy link
Contributor Author

pmoust commented Apr 2, 2014

No problem.

@pmoust pmoust closed this Apr 2, 2014
@pmoust pmoust reopened this Apr 2, 2014
@pmoust
Copy link
Contributor Author

pmoust commented Apr 2, 2014

Just checking something on Travis.

@samdark
Copy link
Member

samdark commented Apr 3, 2014

I like these changes. I think we need to reconsider its usage.

@samdark
Copy link
Member

samdark commented Apr 3, 2014

It seems you've enforced jQueryUI dependency on framework. It should not be downloaded if jui package isn't used.

@pmoust
Copy link
Contributor Author

pmoust commented Apr 3, 2014

You are right, moving it to jui package.

@samdark
Copy link
Member

samdark commented Apr 3, 2014

yii2-dev is fine but yii2 should not include it.

@samdark
Copy link
Member

samdark commented Apr 3, 2014

Are hooks called for dependent packages and not only the main pacakge?

@pmoust
Copy link
Contributor Author

pmoust commented Apr 3, 2014

@samdark how would you like the hooks to be called? I would prefer to not even have hooks but introduce bower to be honest.

For jui package I would suggest adding a bower.json with the dependency, and be called from there. I could automate that for all the packages that have a bower.json I suppose. I could even introduce a static method to be called from within Yii as helper to run bowerphp if you think it is crucial.

@samdark
Copy link
Member

samdark commented Apr 3, 2014

We'll not bundle jQuery or jQueryUI with the framework itself or with any of framework extensions. Current state of jQueryUI files is temporary.

@samdark
Copy link
Member

samdark commented Apr 3, 2014

There will be 2 automatically updated mirrors with composer pacakges: https://github.com/yiisoft/jquery and alike https://github.com/yiisoft/jqueryui that isn't set up yet. These are updated automatically and not taking our time if this is concern.

@pmoust
Copy link
Contributor Author

pmoust commented Apr 3, 2014

Well @dmtrs has argued about that in #2946 (comment) I don't have much to add to that.

Since you are in the FIG and know a few people, perhaps point them to this thread to bring it down to Composer, see if they can figure it out at their own level.

I would be more content if you accepted this PR, but no hard feelings, we can live without it as well.

@samdark
Copy link
Member

samdark commented Apr 3, 2014

@pmoust that argumentation doesn't affect technical aspect of the framework itself. Framework would work by default w/o bower just fine. If one want to use bower in his app, there are no obstacles to do it at all.

So it's not about technical aspect all. It's about if we want to force usage of bower or not.

@samdark
Copy link
Member

samdark commented Apr 3, 2014

I can say that PHP-FIG discussion will result in decision that it's out of scope of PHP serverside framework to force using one particular package manager for frontend that has nothing to do with serverside framework.

@pmoust
Copy link
Contributor Author

pmoust commented Apr 3, 2014

It is related with interoperability in a broader sense. Since Composer is the de-facto package manager for PHP and our frameworks are widely used in frontend scenarios as well, supporting interoperability with other repositories/managers would be nice.

As far as PHP-FIG is concerned, perhaps an AssetManager PSR could be a route to follow to standarize handling those non-php assets that are used in PHP projects. That said, I don't have the time to place in the effort to back this up with a draft for discussion.

@samdark
Copy link
Member

samdark commented Apr 3, 2014

It would be FIG task but not PHP-FIG one. As far as I know, there's no broader FIG group.

AssetManager has nothing to do with external dependencies. It basically doesn't care how files are ended up at your server.

@samdark samdark closed this Apr 3, 2014
@dmtrs
Copy link

dmtrs commented Apr 3, 2014

It would be FIG task ... As far as I know, there's no broader FIG group.

@samdark I hope you understand what you just said is non sense.

@samdark
Copy link
Member

samdark commented Apr 3, 2014

It makes sense with missing part you've removed.

@dmtrs
Copy link

dmtrs commented Apr 3, 2014

Sorry, was referring to a FIG, a boarder FIG group. The removal was to emphasize the global, all mighty group that if it would exist it would be the go to place to get an answer if we should or not should use a tool.

@samdark
Copy link
Member

samdark commented Apr 3, 2014

Yeah but there's no such group. PHP-FIG is all about PHP and frameworks and never crosses the line.

@pmoust
Copy link
Contributor Author

pmoust commented Apr 3, 2014

@samdark I am talking about PHP-FIG and how there should be a standard on how external dependencies (those not into the target of PHP-FIG) like css/js frameworks/components, font packages, images whatever are handled as assets. But this is derailing the point of this PR here.

Also @dmtrs is bringing up the point that indeed such broad FIG group does not exist, nor will in the near future, nor it is a supreme entity that we can call out for.

You are in favor of forking packages and get them served from Packagist, fine. Let's at least not keep those assets within the framework itself or the extensions themselves.

Should we fork every non-php dependency to be handled by Composer? I would not say so.

I think we can come up with an elegant solution. Perhaps you are not satisfied with the route this PR is going (thus closing it), but I would really call you as well as other core developers and contributors to give some more thought and input.

@samdark
Copy link
Member

samdark commented Apr 3, 2014

You are in favor of forking packages and get them served from Packagist, fine. Let's at least not keep those assets within the framework itself or the extensions themselves.

jQueryUI will be moved out of core/extensions. I'm not really in favor of our own packages for jQuery and jQueryUI but it's less of the evils. Forcing developers to use one particular frontend scripts manager isn't the right thing for PHP framework to do.

Should we fork every non-php dependency to be handled by Composer? I would not say so.

If you prefer bower, use bower. Yii uses only 2 such composer packages: jQuery and jQueryUI.

Perhaps you are not satisfied with the route this PR

The correct way to solve it is to push the topic and a solution very hard to composer project. If it will be in, all the technical and non-technical problems will be solved and, I guess, Composer will allow you to use any of frontend package managers same as it allows to use PEAR/zip archives/git/hg/svn etc.

@pmoust
Copy link
Contributor Author

pmoust commented Apr 3, 2014

I have another idea on how to implement this. Will link back on this issue.

@samdark
Copy link
Member

samdark commented Apr 3, 2014

OK.

@cebe
Copy link
Member

cebe commented Jun 29, 2014

Another approach. Comments and help welcome.
https://github.com/cebe/composer-bower#composer-bower

@creocoder
Copy link
Contributor

creocoder commented Jun 29, 2014

@cebe Vote strictly against it. No need reinvent the wheel. Need bower packages — use original bower which is near to be standart for frontend package management. Why need another "very strange" and infamous solution when you can just take bower and use it? Try it. It very simple to do and you'll save your time instead of creating another no one needs library.

P.S. I apologize for the tone of the message. But you not first guy who try to pervert composer goals. All such ideas fail in past. And thanks to god it fail. Because this is wrong from ideological point of view. Composer born to be php package manager. Its not package manager for everything. Need frontend package managing use frontend package managers. Its simple. Involving composer into this is just BIG mistake.

@pmoust
Copy link
Contributor Author

pmoust commented Jun 29, 2014

@cebe this is a fine approach
@creocoder this is not a 'very strange' solution. It's actually clean enough. I see some reasons not to use it, but these reasons are not related to it using packages from other sources, they are related to composer/packagist itself (namely no signed libraries/packages).

I would welcome a solution for a unified point collect all dependencies for a project. The approach @cebe is taking is the approach I was taking when mentioning that I' d close down the hack-ish PRs for something more elegant.

@pmoust
Copy link
Contributor Author

pmoust commented Jun 29, 2014

Oh, one more thing @creocoder , nobody is claiming Bower is not simple. We use it our daily dev/devops life. A tool like that implemented by @cebe helps keep the external dependencies in a single document reference and limit the fetch for those deployments in 1-2 calls.
I am not sure if many people will use it in the end, but I know I'd use it when it's stable.

@cebe
Copy link
Member

cebe commented Jun 29, 2014

@creocoder

  1. it is not a new library, it is a composer package source that provides package information readable by composer.
  2. using only bower for frontend will work in your application just fine. But when it comes to creating yii extensions mostly widgets that require php code and js code in different versions you create a huge mess when you need two package managers to install a single library. I am happy to hear alternative solutions to this problem but "just use bower" is not one.
  3. composer actually is designed to install more than just php. Its internal structure is quite abstract so it is easily possible to use it to depend on other package sources.

@pmoust there are some issue open in the new repo, could need some help in implementing things :)

@creocoder
Copy link
Contributor

creocoder commented Jun 30, 2014

@cebe

I am happy to hear alternative solutions to this problem but "just use bower" is not one.

In reality there is just NO other options instead of using original bower or other frontend package manager if you goal is follow web dev bestpractice ofcourse, if not you can to use any composer exploits/plugins/workarounds/super ideas.

What about alternate solution for "contrived" problem. Just copy assets to extension and publish it. Or simple add to README: "This extension require frontend package xyz version 1.2.3, you can get it adding xyz: 1.2.3 to yours bower.json (modern developer way) or copy to your webroot (caveman way) directory". But if you plan write requirements for frontend package inside extension composer.json, than sorry i'll better use plain js or write mine version of such extension to support modern way of installing frontend libraries and most important to prevent promotion of bad practice.

@pmoust
Copy link
Contributor Author

pmoust commented Jun 30, 2014

Care to explain how this is bad practice exactly? Is there something that is not covered by this approach regarding at least Bower packages? Or is it a philosophical stance (which I do accept as a valid point of discussion)?.

I am not being hostile, I genuinely want to know.

@pmoust
Copy link
Contributor Author

pmoust commented Jun 30, 2014

And perhaps we should move to the other PR and let this #2965 RIP

@samdark
Copy link
Member

samdark commented Jun 30, 2014

Yep. I propose discussing it at https://github.com/cebe/composer-bower

@yiisoft yiisoft locked and limited conversation to collaborators Jun 30, 2014
@cebe
Copy link
Member

cebe commented Jun 30, 2014

more precisely: cebe/composer-bower#5

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Linked issues

Successfully merging this pull request may close these issues.

None yet

6 participants
You can’t perform that action at this time.