composer.json issue with punycode1.3

[shenril]

When i run composer update --dev --prefer-source

Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - yiisoft/yii2 2.0.1 requires bower-asset/punycode 1.3.* -> no matching package found.
    - yiisoft/yii2 2.0.0 requires bower-asset/punycode 1.3.* -> no matching package found.
    - yiisoft/yii2 2.0.0 requires bower-asset/punycode 1.3.* -> no matching package found.
    - Installation request for yiisoft/yii2 * -> satisfiable by yiisoft/yii2[2.0.0, 2.0.1, 2.0.2].

with composer.json :

"require": {
        "php": ">=5.4.0",
        "yiisoft/yii2": "*",
        "yiisoft/yii2-bootstrap": "*",
        "yiisoft/yii2-swiftmailer": "*",
        "yiisoft/jquery": "1.10.*"
},
    "require-dev": {
        "yiisoft/yii2-codeception": "*",
        "yiisoft/yii2-debug": "*",
        "yiisoft/yii2-gii": "*",
        "yiisoft/yii2-faker": "*"
    },
    "config": {
        "process-timeout": 1800
    },
    "extra": {
        "asset-installer-paths": {
            "npm-asset-library": "vendor/npm",
            "bower-asset-library": "vendor/bower"
        }
    }
}

Any idea to solve this ? Fresh installation of Yii2 seems fine which is a mystery to me...

[cebe]

try removing your vendor directory and run again

[onman]

I just ran into the same problem. When checking the yiisoft/yii2 package on packagist (url: https://packagist.org/packages/yiisoft/yii2) it appears that the required bower-asset/... packages don't exist on packagist.

As I am not using the basic-app or advanced-app application structures, this is very awkward.

[antonkomarev]

@cebe gave a right solution, it's confirmed multiple of times: https://github.com/yiisoft/yii2/issues/7402#issuecomment-75649429

[creocoder]

try removing your vendor directory and run again

Its super suggestion ) I lost count how many issues we already have with using fxp/composer-asset-plugin. And this is price of wrong decisions in past.

[cebe]

@creocoder if you read carefully the docs of the plugin this is the thing to do when you downgrade packages because it makes a lot of speedup by skipping versions lower than the installed one.

This is also in most cases the solution to problems with composer without the plugin. Composer is still alpha, it is itself not really versioned so one can not ask for a composer versoin that is used because in many places you have another dev version installed. Thats also a big part of the problem.

[creocoder]

@cebe I do not care about plugin documentation. This plugin is dirty hack on top of composer. I prefer composer team prevent possibility to write plugins like that. Why such negative? Simple, every day i have troubles with that plugin (incredible long time working, consistent troubles with fetching packages). Am i one hate this part of Yii 2? No. I talked to many people who involved into deploy Yii 2 applications. System administrators hate this plugin since it need to be global. Frontend devs hate this plugin and our workflow and consider us crazy perverts. Many times i hear from colleagues something like lets replace this with another framework, but i defend Yii 2 since i love it. On other side I and lot of people wait for 2.1 where I hope we finally will avoid using things like that. In php world only Yii 2 have such specific troubles.

This is also in most cases the solution to problems with composer without the plugin.

Never have any troubles with composer without that plugin.

[cebe]

System administrators hate this plugin since it need to be global.

They have no problem installing global npm javascript things on the server?

I'd like to see how other frameworks handle this kind of thing, as far as I am aware they just do not handle it because they do not provide much frontend stuff.

I am open for alternative solutions to this but I think we should open a new issue for this and define clearly what we need to achive before pushing into different directions.

[onman]

I overlooked I had to install the fxp/composer-asset-plugin. After installing it, composer ran like a charm.

[creocoder]

@cebe

They have no problem installing global npm javascript things on the server?

Ofcourse not, do you have idea how node.js popular in compare with Yii 2 and this specific plugin? A hundred times more popular, maybe? Node.js on servers is standart nova days since there is bower package manager which require it, since there is grunt/gulp. System administrators does not have idea how some people can code withour such tools. So ofcourse there is no any troubles with node.js on servers.

I'd like to see how other frameworks handle this kind of thing

Look at Laravel, look at Symfony, look at on Zend. Sorry, but they does not solve non existent troubles. Mine personal experience with Laravel cleanly shown that writing V layer with it several times faster than with Yii 2.

P.S. Asset bundles approach, solutions for it compression and minification, all widgets, yii2-bootstrap and similar widgets is complettely wasted time.

[cebe]

Well, my experiences with installing nodejs was always ending in a dependency mess on my machine with several ppas from dubious sources serving my finally working version of the stack... I do not want to have this on my production server.

afaik (correct me if I'm wrong) the other frameworks mentioned do not integrate that much with frontend code like yii does for example with widgets e.g. activeform.

[onman]

I (and others near me) find that using yii2 enforces too many other packages on us. When I want to install yii core, that's all I want. I guess a better separation between the core framework and add-ons using the framework would improve things a lot.

The core framework could be yii\base, db and ar, validators, RBAC, MVC and application classes. In other words the things that don't cope with the UI and things that don't require third party stuff. Base widget classes (and possibly widgets that are UI independent) can still be part of the core.

Everything else would be in separate packages. This would be things like the email component (using swiftmail), GUI components using jQuery, bootstrap, etcetera. I guess bower could then also taken away from the core.

The yii team has made a good start by separating modules like gii and debug into separate packages. But there's room for improvement in this area.

[creocoder]

@cebe

afaik (correct me if I'm wrong) the other frameworks mentioned do not integrate that much with frontend code like yii does for example with widgets e.g. activeform.

ActiveForm/ActiveField is great example of antiproductive and useless (except primitive cases) widgets. First of all it insist on its own validation solution. Second it does it not agile and have significant limitations. Third it "too smart" and naively believes that all form groups should have container and to show some error this container should change css class. Fourth. Sometimes it become mess of php and html (in templates variables). In reality i saw people who stuck with ActiveForm on implementing complex form with day or even more and result was horrible, mess of php and interpolated html code. Moreover that time is enough to 10 times make this form on html + some html helpers and you'll even win time to learn jquery validation plugin or analog to make client side validation.

About other frameworks...

Symfony 2 have powerful form builer: http://symfony.com/doc/current/book/forms.html Zend Framework 2 have powerful form builder: http://framework.zend.com/manual/current/en/modules/zend.form.intro.html

Laravel use simple html helpers to generate any kind of form, Its absoluttely agnostic to any css frameworks and does not make any assumptions about it structure. You just make any form you want using pure html + such helpers. As result you'll get cleanest form.

All 3 frameworks not reinvent wheel at field of client side validation and suggest user decide best option around that. Novadays there is lot of approaches. Someone use AngularJS and it solution, some use jQuery and plugins for it, someone use ReactJS. Backend framework should not care about client side validation. If you want do best maximum you can do is provide set of validators for most popular frontend solutions to ensure backend validators sync best way with client side validators. Reinventing wheels on that field was very bad idea. In Yii 1.1 it was fine because it was long time ago, in Yii 2 looking on that, looking on validators with jquery (worst choice to create frontend solutions novadays) client side code on board is just strange.

[creocoder]

@cebe Sorry for criticism. Today I feel myself as Yii 2 critic ) It might be helpful to make right decisions inside Yii 2.1. I promise to continue love Yii 2 starting from tomorrow ;)

[qiangxue]

@creocoder You don't have to turn 180 degree against something you are criticizing. Such exaggeration makes your words less credible than it could be.

If you don't want to use client-side validation of ActiveForm, just disable it. If you don't like ActiveForm, just use plain HTML helper methods or code. It may be true for your particular use case, using the built-in ActiveForm is counter-productive. Then just don't use them. No one is forcing you to use them.

I am curious though: when you use third party validation solutions, how do you keep consistency between server-side and client-side validations? Do you have to copy the same error messages on both sides? What about the consistency of validation rules on both sides?

I also wonder if you really have used SF and ZF's form builders. It's funny that you would claim their solution is more powerful while by default they also enforce certain HTML structures. It seems to me you use them as an example just for bashing purpose.

Regarding the asset bundle thing, we already had a long discussion before. We all agree the current solution is not perfect, and we are thinking and experimenting in practice to come up with a better solution. Your proposal earlier on was a good one, but there was still a big gap.

[creocoder]

@qiangxue

If you don't want to use client-side validation of ActiveForm, just disable it. If you don't like ActiveForm, just use plain HTML helper methods or code. It may be true for your particular use case, using the built-in ActiveForm is counter-productive. Then just don't use them. No one is forcing you to use them.

Its not about technical troubles. I can disable anything and use any alternate solution. Trouble is about business and companies which use framework. I would also like to believe that the world is perfect, and all coders geniuses. But in reality i saw lot of Yii 1 applications and Yii 2 applications from real people, from real companies. I said ActiveForm is counter-productive in most cases just because i see php + html mess inside most of them. Majority of coders i meet belive that if fw suggest something this solve most use cases. And this is true with most of Yii components except of ActiveForm. Its propaganda in reality lead to situation when it used for everything.

I am curious though: when you use third party validation solutions, how do you keep consistency between server-side and client-side validations? Do you have to copy the same error messages on both sides? What about the consistency of validation rules on both sides?

As i said in my previous post smart decision is provide set of client side validators for popular client side solutions vendors. As i saw most of them have architectures which make it extensible. By doing so you have such consistency garantee. This is similar to why pjax instead of reinventing wheel again was used inside Yii 2.

I also wonder if you really have used SF and ZF's form builders. It's funny that you would claim their solution is more powerful while by default they also enforce certain HTML structures.

It was just answer to @cebe question around other fw solutions. I just call such builders powerful because i know ppl who use it for every-day development and they claim any form can be builded with that. But its Enterprise while we are RAPID. I do not call such solutions more powerful than others. Its just other approach of creating forms. Laravel use similar to ours Yii 1 ActiveForm solution which i think was more interesting and agile than current. Yes, current has less code in some cases, but in real practice cases it usually lead to php + interpolated html mess.

[qiangxue]

As i said in my previous post smart decision is provide set of client side validators for popular client side solutions vendors. As i saw most of them have architectures which make it extensible. By doing so you have such consistency garantee. This is similar to why pjax instead of reinventing wheel again was used inside Yii 2.

You still haven't answered how do you ensure consistency between server-side and client-side validations. Or do you mean we only need client-side validation?

I just call such builders powerful because i know ppl who use it for every-day development and they claim any form can be builded with that. But its Enterprise while we are RAPID. I do not call such solutions more powerful than others. Its just other approach of creating forms. Laravel use similar to ours Yii 1 ActiveForm solution which i think was more interesting and agile than current. Yes, current has less code in some cases, but in real practice cases it usually lead to php + interpolated html mess.

When you use form builders, you are already mixing PHP and HTML code. And as I said ActiveForm doesn't attempt to solve all form creation tasks. It's actually like a form builder and attempts to solve a set of common tasks. It seems you are contradicting to your own arguments.

[creocoder]

@qiangxue

You still haven't answered how do you ensure consistency between server-side and client-side validations. Or do you mean we only need client-side validation?

Frontend client side validation solutions is library itself + validators. We can just use our solutions only for library validators (to have 100% sync with backend validators) but use library as main background. If inventing own solution is most wanted way its OK, sometimes reinventing wheels lead to something revolutionary, but in that case we need make this solution opened to frontend world to have more feedback.

When you use form builders, you are already mixing PHP and HTML code.

This is not true in case of Symfony and Zend builders. It used inside controllers and have its own views for rendering. I can agree that ActiveForm is similar to real form builders (which mean implementing of Builder pattern), but its far from classical solutions around that.

[creocoder]

@qiangxue A simple example about client side validation. For example we decide use http://jqueryvalidation.org/ which is very popular and near to finish Pledgie campaign for next enhancements. It can be easily extended by own set of validators. I'm sure it will not neccesary for all validators we can reuse lot of buildin. But if it needed we can use $.validator.addMethod("someValidator", function(value, element, params) { ... }).

[qiangxue]

Frontend client side validation solutions is library itself + validators. ...

Then you still need to find a way to integrate 3rd-party lib and our validation rules. Such a task is not trivial at all. And your argument essentially is that everyone should do this by himself and it is more productive. Again, you are fully free to develop such an integration as an extension. If it is proven to be better than the core solution, people will love it more for sure.

This is not true in case of Symfony and Zend builders. It used inside controllers...

Do you really think it's a good practice to build forms (such as specifying button labels) inside controllers? I know ActiveForm is not close to the so-called classical form builder (yii 1 has such one). If you like form builder so much, why not creating such an extension? Wouldn't this prove your earlier argument that we should encourage reinventing wheels sometimes?

[qiangxue]

Let's end this debate as it is not very productive. If you find a better solution than the core one, feel free to show it in a concrete form or even release it as an extension. If it is well adopted, we are open to replace the core solution with it.

Having an idea is not very difficult, but caring for the details often takes a lot of efforts.

[creocoder]

@qiangxue

If you find a better solution than the core one, feel free to show it in a concrete form or even release it as an extension.

Will try to make extension for http://jqueryvalidation.org/ . These thoughts I have for a long time.

P.S. Thanks for conversation! )