Bower package manager instead of Packagist for jQuery

[pmoust]

Relates to #2946

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

[pmoust]

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

[cebe]

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

[cebe]

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

[pmoust]

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]

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]

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

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]

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

No problem.

[pmoust]

Just checking something on Travis.

[samdark]

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

[samdark]

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

[pmoust]

You are right, moving it to jui package.

[samdark]

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

[samdark]

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

[pmoust]

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

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]

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]

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]

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

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]

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]

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.

[dmtrs]

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]

It makes sense with missing part you've removed.

[dmtrs]

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]

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

[pmoust]

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

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]

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

[samdark]

OK.

[cebe]

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

[creocoder]

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

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

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]

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

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

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]

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

[samdark]

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

[cebe]

more precisely: cebe/composer-bower#5