Problem installing venne/nette.ajax.js using composer

[josefsabl]

Problem installing venne/nette.ajax.js using composer

[vojtech-dobes]

This is not issue of nette.ajax.js. Please use Bower to install nette.ajax.js as dependency. For history.nette.ajax.js, there is Composer package vojtech-dobes/nette-ajax-history available.

[josefsabl]

Ok, is this the correct place to report this problem?

https://github.com/pepakriz/nette.ajax.js

I really don't want to install yet another packaging system. Thanks

[vojtech-dobes]

Yeah, I guess so.

I really don't want to install yet another packaging system. Thanks

Sure, but I think it's antipattern to install non-PHP stuff via Composer, dependency Manager for PHP :).

[josefsabl]

I see :-) But it works surprisingly well, especially with Webloader. Thanks!

[mishak87]

When I go to buy groceries I use forklift instead of basket because it is so convenient.

[josefsabl]

When I think of it, I don't see antipattern at all.

Composer is dependency management for PHP, sure. But my project IS php. And it has dependencies. It depends on certain PHP version, some PHP extensions, some javascript and some css.

What does it matter that php extensions are not programmed in php? They are probably c++ or something. Moreover: PHP project is NOT made out of PHP code only. It has js, css, html, configs etc...

[mishak87]

There is difference between assets only (front) and PHP website. This is only front project. And history is PHP project with assets. But it is still advantageous to use both bower and composer for mixed projects. It is not anti-pattern for front project to use composer it is misuse of a tool. Do you go to rob store because you want to withdraw money from bank? Result might be the same but you are using wrong approach.

OT: Extensions are part of PHP ecosystem and AFAIK you can't install them via composer it only lets you know when they are missing.

[josefsabl]

Your analogies are pretty weird. I don't think that shopping with forklift is any convenient and robbing a bank has absolutely different outcome than withdrawing money (one lowers your balance, second sends police shooting at you).

Anyway, I am not sure why using Composer to install front technologies is bad apart that it has "for PHP" in its sub-title.

I am not saying it is not true, I just don't get it.

What is the difference between assets only and PHP website and why should I care?
Why is it advantageous to use both? Drawback: two different systems; Advantage: ???
Why is using composer to install javascript misusing. Where is it said that I sould not do it?

[mishak87]

The desired outcome is obviously having cash. The first one has unwanted side-effects and is against concept of withdrawing money.

A) Assets don't need backend code to work and are not dependent on PHP. Usually you see dependence only because of history ie. nette-forms (assets) vs nette/forms (PHP project).
B) Decoupling and simplicity, I can write different backend while using your assets and vice versa. (It might be worth splitting into two repositories because assets and backend development does not always goes together. Especially after first version.)
C) It is not said anywhere. Did you ever thought about using dpkg to install your php dependencies? I guess not. That it is convenient does not mean it was intended or mean to be.

How do you define dependency on jquery in PHP project using composer? Do you create composer package for jquery and maintain it? Do you do it for each package?
How do you define where in the repository is the asset via composer?
Is it necessary with each version of your package release new version of unchanged asset?

Asking why should you care is idiotic. I am not here to convince you that you should do it. I am trying to explain why it was done.

I am not sure why using Composer to install front technologies is bad apart that it has "for PHP" in its name.

If something similar is in you response I am done. I won't waste time explaining to someone that composer is package manager specialized for PHP projects.

[josefsabl]

Btw: https://github.com/vojtech-dobes/history.nette.ajax.js/tree/master#installation :-)

[vojtech-dobes]

@josefsabl This extension for nette.ajax.js contains PHP files, therefore uses Composer for them :).

[josefsabl]

@mishak87 I am sorry I angered you. Didn't want to, really. Thanks for your time :-)

Assets don't need backend code to work and are not dependent on PHP.

Nette.ajax.js works without Nette? What does it do exactly? I can see packages that are useful without backend code, but nette.ajax.js is not one of them by my opinion.

I can write different backend while using your assets and vice versa.

Fair enough. I am not advocating against Bower itself. What I am saying is that ability to install javascript code with composer is useful and not antipattern.

Anyway. If you can write separate backend and frontend that are totally decoupled, maybe they are two separate projects that may have separate .json dependency files. But it is not the case of Ajax in Nette which needs Nette and nette.ajax.js.

Did you ever thought about using dpkg to install your php dependencies

Did you ever thought about using one tool to install command line utility and then another tool to install GUI that makes use of said utility?

How do you define dependency on jquery in PHP project using composer?

"require": {
    "components/jquery": "1.9.*"
}

Do you create composer package for jquery and maintain it? Do you do it for each package?

Not me. But obviously there are others who do just that.

How do you define where in the repository is the asset via composer?

"config": {
    "vendor-dir": "vendor",
    "component-dir": "vendor/components"
},

Is it necessary with each version of your package release new version of unchanged asset?

I am not sure if I understand. If the package and asset are decoupled, they should be separate packages and there should be some dependency defined between them.

@vojtech-dobes So now we have one library that is installed using two different package managers? Or maybe history.nette.ajax.js should be split into two packages (history.nette.ajax.js and history.nette.ajax.php)? How do I define dependency between them? I assume that history.nette.ajax.js depends on nette.ajax.js. I installed history using composer, how will I know that I also need nette.ajax.js and which version? And how would I know that I also need Nette itself.

Anyway. I started using history.nette.ajax yesterday and it is brilliant, many thanks :-)

[xificurk]

@josefsabl 👍

[mishak87]

First of all I am never angry here. I just don't like getting dragged into a conversation with troll. Which luckily did not happen after all. Since you did your research and came up with answers to almost all of suggested problems.

Is it necessary with each version of your package release new version of unchanged asset?

I am not sure if I understand. If the package and asset are decoupled, they should be separate packages and there should be some dependency defined between them.

If you have two resources using same manager updating asset part will update code part and vice versa. Even if one of them has not changed or in worst case has changed and is incompatible with previous version (ie. not following semver). P (your project) needs fixed A, but it requires B[>9000], which is not compatible with P.

Using same repository for assets and code is always double edged sword. It is possible when package is just template and assets and versioning follows. But when it is code and asset, declaring dependency for asset in third party library leads to more maintenance and unnecessary incompatibility, since assets are coupled to any and all code changes. This could be solved by versioning asset separately (via explicit declaration) but then you have to manage asset version branches (branches of that asset version number - they are not represented anywhere but in changed file) for each change separately.

So far I have come up only with conventional solution (enforced by hooks, tools and post-scripts) of declaring package for repository <package>-assets in bower with name <package> as composer and including composer.json with requirement of supported versions and vice versa (bower.json for <package> repository). composer.json of assets and bower.json of package repository are not registered and are only used for enforcing dependency via tools (they have just the require section). If this is not clear to you I can make template repositories to demonstrate it.

Solution is maintaining a slightly complicated but error prone package + assets repository system to leverage benefits of flat architecture. But nowhere near complex and open to human errors as one repository multiple packages. Someone can write own implementation (replacing your package) using your assets.

When you understand the connections the rest is just taking advantage of bower without using specific system for php-assets integration via components.
Then you can extend your nette asset manager to parse bower packages and makes them available. That way you don't need third system based on different standard, which front end developers are not using, doing similar but slightly different job.

I was thinking about this past half year, if it makes sense to you we can make it reality (send me mail). I think this approach can significantly reduce time and pain connected with assets maintenance.

Also this is too long and bit OT again, we should probably discuss it on Nette forum or somewhere else.

[fprochazka]

I don't see why the long discussions.

Composer is for PHP dependencies, not for javascript or css or less or whatever frontend technology you use. It's for PHP, there is no point in discussing this any further.

This is a composer thing, go provokoing there.