As an independent project, Composer has free reign over its release cycle and major changes. If it were distributed with PHP itself, it would have to stick to PHP’s release schedule.
It may also have to abide by PHP’s rules on RFCs for new feature development / major changes, and with more developers who are less experienced with it, that may result in delays and bike shedding.
And the package repository, Packagist, would also likely have to come under the PHP umbrella. This may restrict what could be done in terms of Private Packagist, which helps fund Composers development. If that funding was withdrawn, its developers might not be so incentivized to work on it.
It also provides better opportunity for alternative projects to be possible. Someone may come up with a better Composer than Composer. While Composer now has “defacto standard” status, who’s to say whether that might change in the future.
No offense, but especially when we’re comparing Node.js and NPM: none of that is true.
Node.js and NPM are developed by two different entities (e.g: foundation vs the company under Microsoft)– there isn’t any requirement to limit Packagist’s funding or make them one entity.
Node.js and NPM remain independent projects: so they are NOT tied to the release decisions of the other– though they could be if they wanted.
Despite NPM being the official package manager that’s included in their official download: Node.js has a stronger alternative package manager ecosystem than PHP.
NPM and Node.js are far from the only examples that run things that avoid all of the mentioned limitations, but they’re also not a very good example. The NPM project has been plagued with management/alignment problems for years. The multiple owner-changes and security problems haven’t helped.
In general, there can be precautions taken to ensure many of the Node.js/NPM problems are avoided– but those precautions are not necessarily cheap nor worthwhile. It may end up wasting a lot of time to still end up with a company/developer that ignores their community and only promotes their own self-interests.
Thank you, great explanation!
NodeJS is not a language. PHP is programming language.
What you are trying to say is, why isn’t composer integrated in PHP as NPM is to Javascript. The problem is, that NPM isn’t integrated to Javascript.
Does the argument work with ” why isn’t composer integrated in PHP as cargo is to rust” ?
What if…they meant “PHP the runtime”.
It just happens to be that PHP the language is executed by runtimes that are also called PHP. Where as like you pointed out NodeJS is not a language.
I tried at one point to deprecate and remove PEAR/PECL in favor of Composer/Pickle, it didn’t gain traction:
https://wiki.php.net/rfc/deprecate-pear-include-composer
Good try, do you know why it didn’t make the cut ? At which point did you stop ? When there is a vote (it seems that your RFC didn’t reach this step), is there a way, over the people who voted “no”, why they did so ?
I always wondered if it’s possible for example, in the case of your RFC, to do something like a regression-step-vote:
Vote 1: "I agree with this RFC"
Yes/no
Vote 2, If you didn't agree to 1: "I don't agree with this implementation but I am favorable to the global idea of having a package manager shipped with PHP"
Yes/no
It can be helpful in so many cases, knowing if you have to burry your idea for 10 years or if you “just” have to revamp the implementation by working with some experienced fellows.
Anyway, I’m pretty ready to help making this happen again, I’m just totally newbie so my help doesn’t value much.
I’m not sure npm really IS integrated into nodejs, it just generally comes along for the ride when you install node via a package manager.
Also when you download Node from nodejs.org.
NPM isn’t integrated, last i checked i had to install and update them separately.
If you mean “bundled with”: node isn’t a language. It’s not a language’s job to dictate package management systems
Why should it be?
Members
Online