I stopped using PHP. The language itself is fine, but PHP doesn't include a package manager. People will shout "but composer!", That is not PHP. That is a third party tool. What Rust understands, what Go understands, what Ruby understands, is how important the package manager is to the language.
No one is an island, and "batteries included" only gets you so far. In my mind, PHP is in line with C, with the mindset of "figure it out yourself" in regards to packaging. That's not acceptable.
Everyone has standardized on Composer. It's a better package manager than NPM, doesn't have many of the security problems that plague NPM.
The PHP internals maintainers don't have the time to maintain a tool like Composer alongside the rest of the language. And if it was bundled with PHP, it would be stuck in lock-step with PHP version releases, which means improvement can only be made once a year, basically. That's not acceptable. Composer wouldn't be what it is if it had to release so slowly.
> doesn't have many of the security problems that plague NPM
Is that true? How so?
I'm a long-time PHP dev, but of the issues I can recall regarding NPM, including the recent controversy related to the invasion of Ukraine, I don't see how that sort of thing couldn't happen with Composer some day, and it might just be a matter of time; that it hasn't yet has more to do with the relative ecosystems of the two languages and the developers they attract than anything technical, in my opinion. But I'd love to be proven wrong.
With NPM, what's actually published is not what's in the git repo, so it's harder to inspect/review vulnerabilities or hijacking. With composer, what's in git _is_ what composer pulls (with the exception of rules in .gitattributes to exclude files etc), making it much easier to trace. One such example: https://github.com/faisalman/ua-parser-js/issues/536
Composer packages also don't tend to have the "culture" of having a million tiny packages for small functions like left-pad, so that helps a ton too. Mostly because PHP's stdlib is pretty great by default, so lots of things like this don't require 3rd-party libs.
Obviously Composer isn't bullet-proof, someone controlling a dependency of an important project can still cause harm by making a minor version release with malicious code, but it's easier to vet a smaller list of packages in the tree, especially if all you need to do is scan through their code on github.
Thanks for the response. I didn't know that NPM packages aren't just Git pulls as they are in Composer. That's surprising. I wonder why they decided against implementing it that way - it seems like just using Git or other package managers would save from having to deal with hosting, versioning, and so many other things inside the manager system itself.
Generally, NPM packages are transpiled/minified with webpack (or w/e newer tool) and published as minified bundles. That's why it's done that way. It avoids committing the webpack compiled dist to the repo.
With PHP, since there's no compile/minify step, there's no need for "build artifacts", so you can grab the code directly and run it as-is.
But obviously this has big supply-chain security downsides.
> And if it was bundled with PHP, it would be stuck in lock-step with PHP version releases, which means improvement can only be made once a year, basically. That's not acceptable. Composer wouldn't be what it is if it had to release so slowly.
CPAN is bundled with Perl, but CPAN can update itself to a newer version (try `cpan CPAN`). Similarly, NPM is bundled with node.js, but NPM can upgrade itself to a newer version (on Linux/Unix/macOS by running `npm install -g npm@latest`; unfortunately doesn't work on Windows for whatever reason.) Why couldn't Composer use the same model? Composer supports updating itself (when installed as a PHAR) via "composer self-update". So bundle the PHAR with PHP, and then when you run it, can check for a newer version and print a warning if there is a newer version available, and in response to that warning you can run "composer self-update".
It seems like you have an unexamined presumption that bundling a package manager with a language is a superior practice, and you "don't care" about any argument that might challenge that.
Is Ruby Gems a first party thing now? I remember, back in the day, being tangentially involved with creating a Ruby package manager before Gems had become the de facto standard.
Nitpick, but Go the language doesn't have package management. The 'go' tool -- an implementation detail of the most popular implementation -- has features for fetching packages, etc., but the language spec does not require these features or constrain how they work.
No one is an island, and "batteries included" only gets you so far. In my mind, PHP is in line with C, with the mindset of "figure it out yourself" in regards to packaging. That's not acceptable.