Re: [Initial Feedback] PHP User Mo dules - An Adaptation of ES6 from JavaScript

On 29 June 2024 21:20:23 BST, Michael Morris <tendoaki@gmail.com> wrote: >Composer is wonderful as a userland solution to a problem the Internals >team has failed to solve, but such a critical problem as package >management being mostly solved in userland I don't think anyone failed to solve anything. Somebody came along and built a solution, it worked well, and people adopted it. In fact, so many people adopted it that we're in the happy place of not having competing tools, outside of application-specific plugin installers. Its release cycle is independent of PHP's, which means you can get the latest version of Composer whatever version of PHP you're on. It's written in PHP at least in part because there are a lot more PHP programmers willing to maintain PHP tools than there are C programmers willing to maintain PHP tools. If Composer (or some new package manager) was marked as an official part of the PHP project, I doubt it would make any difference to how people find it - users looking at existing projects find it because it's the first line of the installation instructions; new PHP users learning from scratch are probably following tutorials the official project has no control over, which either mention it or not. > using a configuration file >(composer.json) written in another programming language JSON is not a programming language. It looks a bit like JS, because it was invented by a JS developer, but was explicitly designed as a cross-language data format. Some other package managers use other data formats, like XML, or TOML. There probably are languages which use their own source code for that configuration, but I've not come across any. As I mentioned on another reply, it would take an extremely good sales pitch for me to pay any attention to any attempt at a replacement for Composer, especially one that wasn't compatible with its huge library of existing packages. If the sales pitch is "JSON is not the best format for package configuration", count me out. The same goes for a lot of other suggestions in this thread: I'm going to need a pretty strong sales pitch to change my hierarchical namespaces to flat module imports - and more importantly, projects like Symfony and Laravel are going to need that sales pitch, before they break compatibility for thousands of applications built on their current packages. Other parts of this thread are just random rants about things people don't like in PHP, which I have zero interest in, and have nothing whatsoever to do with modules or package management. Rowan Tommins [IMSoP]