Bower package manager instead of Packagist for jQuery #2965

Closed
wants to merge 11 commits into
from

Conversation

Projects
None yet
6 participants
@pmoust
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 some commits Apr 2, 2014

Added Bower package manager support
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

This comment has been minimized.

Show comment
Hide comment
@pmoust

pmoust Apr 2, 2014

Contributor

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

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@cebe

cebe Apr 2, 2014

Member

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

Member

cebe commented Apr 2, 2014

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

@cebe

This comment has been minimized.

Show comment
Hide comment
@cebe

cebe Apr 2, 2014

Member

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

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

This comment has been minimized.

Show comment
Hide comment
@pmoust

pmoust Apr 2, 2014

Contributor

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

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@cebe

cebe Apr 2, 2014

Member

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.

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

This comment has been minimized.

Show comment
Hide comment
@pmoust

pmoust Apr 2, 2014

Contributor

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

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@pmoust

pmoust Apr 2, 2014

Contributor

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"
}
Contributor

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

This comment has been minimized.

Show comment
Hide comment
@qiangxue

qiangxue Apr 2, 2014

Member

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

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

This comment has been minimized.

Show comment
Hide comment
@pmoust

pmoust Apr 2, 2014

Contributor

No problem.

Contributor

pmoust commented Apr 2, 2014

No problem.

@pmoust pmoust closed this Apr 2, 2014

@pmoust pmoust reopened this Apr 2, 2014

@pmoust

This comment has been minimized.

Show comment
Hide comment
@pmoust

pmoust Apr 2, 2014

Contributor

Just checking something on Travis.

Contributor

pmoust commented Apr 2, 2014

Just checking something on Travis.

@samdark

This comment has been minimized.

Show comment
Hide comment
@samdark

samdark Apr 3, 2014

Member

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

Member

samdark commented Apr 3, 2014

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

@samdark

This comment has been minimized.

Show comment
Hide comment
@samdark

samdark Apr 3, 2014

Member

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

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

This comment has been minimized.

Show comment
Hide comment
@pmoust

pmoust Apr 3, 2014

Contributor

You are right, moving it to jui package.

Contributor

pmoust commented Apr 3, 2014

You are right, moving it to jui package.

@samdark

This comment has been minimized.

Show comment
Hide comment
@samdark

samdark Apr 3, 2014

Member

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

Member

samdark commented Apr 3, 2014

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

@samdark

This comment has been minimized.

Show comment
Hide comment
@samdark

samdark Apr 3, 2014

Member

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

Member

samdark commented Apr 3, 2014

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

@pmoust

This comment has been minimized.

Show comment
Hide comment
@pmoust

pmoust Apr 3, 2014

Contributor

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

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@samdark

samdark Apr 3, 2014

Member

We were planning to move jQueryUI to the same package as jQuery i.e. this part won't be different and it won't be bundled anymore. So technically there's no difference from the user standpoint.

As I can see, the only pro/con for end user will be learning about bower.

Member

samdark commented Apr 3, 2014

We were planning to move jQueryUI to the same package as jQuery i.e. this part won't be different and it won't be bundled anymore. So technically there's no difference from the user standpoint.

As I can see, the only pro/con for end user will be learning about bower.

@samdark

This comment has been minimized.

Show comment
Hide comment
@samdark

samdark Apr 3, 2014

Member

Framework itself technically doesn't gain much.

Member

samdark commented Apr 3, 2014

Framework itself technically doesn't gain much.

@pmoust

This comment has been minimized.

Show comment
Hide comment
@pmoust

pmoust Apr 3, 2014

Contributor

Well not bundling dependencies within the framework and/or packages is a gain imho. Same way we are not packing our vendor packages from composer within the framework/extensions themselves.

Contributor

pmoust commented Apr 3, 2014

Well not bundling dependencies within the framework and/or packages is a gain imho. Same way we are not packing our vendor packages from composer within the framework/extensions themselves.

@samdark

This comment has been minimized.

Show comment
Hide comment
@samdark

samdark Apr 3, 2014

Member

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

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

This comment has been minimized.

Show comment
Hide comment
@samdark

samdark Apr 3, 2014

Member

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.

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

This comment has been minimized.

Show comment
Hide comment
@pmoust

pmoust Apr 3, 2014

Contributor

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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@samdark

samdark Apr 3, 2014

Member

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

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

This comment has been minimized.

Show comment
Hide comment
@samdark

samdark Apr 3, 2014

Member

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.

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

This comment has been minimized.

Show comment
Hide comment
@pmoust

pmoust Apr 3, 2014

Contributor

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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@samdark

samdark Apr 3, 2014

Member

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.

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

This comment has been minimized.

Show comment
Hide comment
@dmtrs

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

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

This comment has been minimized.

Show comment
Hide comment
@samdark

samdark Apr 3, 2014

Member

It makes sense with missing part you've removed.

Member

samdark commented Apr 3, 2014

It makes sense with missing part you've removed.

@dmtrs

This comment has been minimized.

Show comment
Hide comment
@dmtrs

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

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

This comment has been minimized.

Show comment
Hide comment
@samdark

samdark Apr 3, 2014

Member

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

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

This comment has been minimized.

Show comment
Hide comment
@pmoust

pmoust Apr 3, 2014

Contributor

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

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@samdark

samdark Apr 3, 2014

Member

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.

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

This comment has been minimized.

Show comment
Hide comment
@pmoust

pmoust Apr 3, 2014

Contributor

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

Contributor

pmoust commented Apr 3, 2014

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

@samdark

This comment has been minimized.

Show comment
Hide comment
@samdark

samdark Apr 3, 2014

Member

OK.

Member

samdark commented Apr 3, 2014

OK.

@cebe

This comment has been minimized.

Show comment
Hide comment
@cebe

cebe Jun 29, 2014

Member

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

Member

cebe commented Jun 29, 2014

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

@creocoder

This comment has been minimized.

Show comment
Hide comment
@creocoder

creocoder Jun 29, 2014

Contributor

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

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

This comment has been minimized.

Show comment
Hide comment
@pmoust

pmoust Jun 29, 2014

Contributor

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

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@pmoust

pmoust Jun 29, 2014

Contributor

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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@cebe

cebe Jun 29, 2014

Member

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

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

This comment has been minimized.

Show comment
Hide comment
@creocoder

creocoder Jun 30, 2014

Contributor

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

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

This comment has been minimized.

Show comment
Hide comment
@pmoust

pmoust Jun 30, 2014

Contributor

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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@pmoust

pmoust Jun 30, 2014

Contributor

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

Contributor

pmoust commented Jun 30, 2014

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

@samdark

This comment has been minimized.

Show comment
Hide comment
@samdark

samdark Jun 30, 2014

Member

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

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

This comment has been minimized.

Show comment
Hide comment
@cebe

cebe Jun 30, 2014

Member

more precisely: cebe/composer-bower#5

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.