7 ms·

What, why and how of PHP Composer

sshine 8y ago
The short version: If you're a PHP developer, here's why you should use a package manager instead of downloading zip-files.
pasta 8y ago
After using Composer for some years I think these tips are good to think about: * Use full version numbers for your dependencies. * Include the vendor folder in your VCS. The last one I had to think about a lot but it's a real pain to get an old project working again when dependencies are no longer available. Unfortunately this happens a lot.
- stunt 8y ago
  You always choose a reliable dependency not something random. I never had similar experience or saw a project doing that. You should only version composer.lock and composer.json files. Ignore vendor directory and leave that job to your build step in CI/CD...
  - viraptor 8y ago
    Things disappear, or get deleted, or old versions get replaced for various reasons. There's no "reliable dependency". Even if you think something's reliable, sone deeper dependency may disappear. See npm and left-pad for example. Committing vendor directory may or may not be a good idea. But having your own copy of all dependencies (current and past) is necessary.
    - marenkay 8y ago
      > But having your own copy of all dependencies (current and past) is necessary. Definitely! Git mirrors are cheap, and there are various solutions for composer proxies out there. If you consider CI/CD you will want freedom from external calls anyway.
  - mnemnc 8y ago
    That's why we have our own composer repository powered by satis. When set up correctly, it can be used as a "proxy" for packagist, ensuring you always have an installable version of your dependencies, even if they are not available via packagist anymore.
    - dotancohen 8y ago
      Most insightful comment on this thread. I'm looking into satis now, thank you! https://github.com/composer/satis https://github.com/composer/satis
- marenkay 8y ago
  Major and minor versions usually are sufficient, as you can lock to a specific version anyway. You should never VCS the vendor directory. If you are concerned about disappearing 3rd party dependencies, you should: - have a local cache - keep e.g. git mirrors for 3rd party dependencies - invest a bit more time in selecting dependencies with higher quality. I've seen repos with vendors checked in. A few years, hundreds of thousands of commits, and even a git status takes 30 seconds to run. Just saying, there is a more sensible approach that beats storing vendors in the project :-)
  - pjmlp 8y ago
    While sensible advice, usually only the VCS approach works across many organizations, which don't provide the resources to do it in any other more reasonable way.
  - deleted 8y ago
    [deleted]
  - gkya 8y ago
    Checking your dependencies in is a good idea. When you check out a version from some time ago, you won't have to worry if those versions are still available in your cache or on remotes. Especially if the package manager is not very dependable. Furthermore, if you patch or edit your dependencies, that information is permanently recorded too.
    - sopooneo 8y ago
      At my job we almost never version control our vendor directory, but you have a very strong point, and I am not strongly in our camp. One pain point in particular, is that if you are using Git Bisect to find out where a bug appeared, and you don't have your dependencies version controlled, you either have to run "composer install" at each bisect step, or set up an equivalent checkout hook. And while I guess the checkout hook could work, it is going to make a lot of other work a lot slower.
  - roel_v 8y ago
    "and even a git status takes 30 seconds to run" That's a problem with your vcs, not with the (defensive) practice of tracking external dependencies.
- fredsted 8y ago
  Your build system should take care of this for you. For example, build a docker image or store an artifact (e.g. zip file) of the full build including dependencies. Then put it on your own docker registry or the artifact on S3, for example.
- waibelp 8y ago
  Instead of including the vendor folder into projects you may use satis [0] to "mirror" all of your dependencies. That means you will not have any broken stuff if packagist is down or any of your dependencies are missing. [0]: https://github.com/composer/satis https://github.com/composer/satis
- Seldaek 8y ago
  IMO for the first point you should rather use ^x.y with the minimum version you require and then accept new releases as they come. If you do regular updates you should notice quickly when something break and be able to revert that update easily. If you update 20 packages at once it becomes harder to pinpoint where a regression occurred. As for including the vendor dir in your VCS repo, this comes with quite a few drawbacks. That's one of the things Private Packagist (https://packagist.com https://packagist.com) aims to fix though, as it keeps mirrored copies of your dependencies' zip archives so you get more reliable installs.
  - Double_a_92 8y ago
    What guarantees you that packagist will be around in e.g. 15 years when you would like to start some old project?
    - Seldaek 8y ago
      If you are talking about such long time frames, then indeed archiving a project with its vendor directory might be a good idea once you decide to relegate it to the freezer.
      - Piskvorrr 8y ago
        How about "vendor decided to migrate off Github last week, and managed to break all their tags in the process"? (Not that this would have actually happened to me this Monday, noooo ;)) Long timeframes are not the only issue with external dependencies...
    - krapp 8y ago
      You don't need (and shouldn't depend on) packagist when using Composer. You can import packages directly from Github, Bitbucket, etc., or even locally, you just have to write a bit more JSON.
      - mrrsm 8y ago
        What do you suggest when the package you are using is pulling in other packages from packagist?
- hrktb 8y ago
  > * Use full version numbers for your dependencies. The tradeoff for this approach is to have to resolve version conflicts manually anytime there is more than minor dependency changes. In particular, adding a package that is newer than most of your dependencies can be a nightmare when you locked down all the working revisions of your libraries. On one hand there is less drama about packages changing under one's feet, on the other hand part of composer's job is shifted back to the dev who does the package updates. Personally I would advise a more balanced approach of allowing minor version changes and only block major ones.
dvfjsdhgfv 8y ago
So I just wanted to try Laravel Factory. I was likely to buy it as I tried some Laravel CRUD builders in the past and each had some flaws that your project seems not to have. However, I couldn't complete registration as you don't allow disable throwaway domains. I just wanted to let you know it makes no sense whatsoever. I never disclose my real e-mail addresses at that stage. Just wanted to let you know - and also others who make the same mistake. If you don't want my money, that's OK.
- welly 8y ago
  Just tested it myself with guerillamail and mailinator. And as you say, "Disposable email addresses are not allowed". I get why they'd do this because obviously they want to capture potential buyers of their software to pester at a later date to buy but I'm not a potential buyer until I've tried it. So I'm another one that won't be handing over any money.
- danieltillett 8y ago
  It is quite possible that they have found that people who use disposable email accounts never buy anything. My company also blocks disposable email address because we found that people using them were just abusing our service and our sales went up after doing so. The funny thing is apart from emailing the free code we almost never contact anyone since we know 99% of our free users are not potential paying customers and so there is no point wasting our time on them. We only know this because they give us their real email address which allows us to screen them out.
  - dvfjsdhgfv 8y ago
    Maybe for some services that you can abuse blocking disposable addresses might make sense, but not for this one. In any case, I finally decided to register using a throwaway spambox from Gmail instead of Mailinator (what difference does it make, really...) and it turns out the Laravel Factory is inferior to Voyager as it doesn't support roles out of the box. Which is a pity as other things have been solved quite nicely. I'll give it a try in a few months, maybe they catch up.
chx 8y ago
The fundamental problem with composer is it goes and updates everything even when I just want it to deal with a single package. And then, of course, because so many packages promise but can't keep proper semver, things break. Marvelous. Coupled with arcane version syntax (Drupal's version system predates Composer and it used natural syntax like foo (>=2.1.1) bar (2.x) so all they needed to do is to take the about 30 lines of well commented code, no need to memorize a list of sigils but no), excruciating slowness makes me wish I never heard of it much less need to work with it daily.
- Seldaek 8y ago
  Updating single packages is very much possible, see https://getcomposer.org/doc/03-cli.md#update https://getcomposer.org/doc/03-cli.md#update - as for semver promises, that's really up to you and which packages you decide to trust, nothing the tool can do about it.
  - chx 8y ago
    Note I said "deal with", it's not update, I learned long ago never to touch composer update. I think it is require that does this. Or that install doesn't have a single package argument? Whatever. I am not alone in finding the only way to actually use composer is to nail down every single package to a single version. Do note I didn't write https://github.com/webflo/drupal-core-strict https://github.com/webflo/drupal-core-strict which is just that https://github.com/webflo/drupal-core-strict/blob/8.5.4/composer.json https://github.com/webflo/drupal-core-strict/blob/8.5.4/comp... As for trust, noone in the PHP world! Absolutely noone! I got into a debate with Rasmus about the meaning of backwards compatibility around the time PHP 5.4 began to throw additional warnings (not a new class of errors which could be additionally displayed, no) on code that previously worked. Drupal 8.4 released with a known bug that caused some code to merrily lose files uploaded by users because of a BC break. If you want BC, look at the kernel Linux API and even the ABI.
    - jtreminio 8y ago
      > Or that install doesn't have a single package argument? `composer require {vendor}/{your-amazing-package}:{version}`
joemaller1 8y ago
The Composer project and Packagist are the catalysts which made it possible to drag PHP development out of the dark ages, but it's still got some rough edges that will eat a afternoon. Recent example: Re-organizing namespaces and classes in an internal library. Losing my mind (doing everything right) until finally realizing Composer wasn't updating the autoloader to reflect changes to the lib's composer.json. For something that works really well when it’s working, I have blown a lot of hours fighting with this stuff.
- steve_adams_86 8y ago
  Rebuilding the autoloader became a normal step in diagnosing issues for me. You never know... These days I deal with npm which in some ways is nicer yet it can still eat afternoons.
  - mkirklions 8y ago
    So far no issues with PHP other than the occasional turn it off and back on again. NPM? Wake up on a saturday morning and hot reload + react tools no longer works? F me. On the bright side I almost finished the front end, so I can casually mess around with the solution every few days as I do my daily work in laravel.
    - steve_adams_86 8y ago
      Haha, fair enough. The other day I was getting this bizarre mismatch of versions of a dependency and I couldn't figure out how it could even matter. Like, who cares if they're two minor versions apart? Neither of them were global so there was no conflict for their parent modules. _That_ is the kind of stuff that kills me about npm. It can be really reeeaally hard to figure out what to do in those situations. Also, package.json is arguably a pretty gnarly way to organize... Well, everything? It's the kitchen sink of configuration, but it's supposed to be for managing packages. But no, you can also configure your packages in there, configure scripts for your application, etc. It's nuts. Even so, both of them are miles ahead of what we had 10 years ago!
- 8y ago
NickHoff 8y ago
There's a zero-width-joiner and then a space at the start of this title. It's &zwj; What, Why and How of PHP Composer The zwj doesn't print (of course) but the space does, causing the alignment of titles on the front page to be slightly off. It tweaked me. Always looking out for the important things...
- severine 8y ago
  And it won't show in our history...
- Operyl 8y ago
  This is the only reason I decided to click into the comments, even.
- danso 8y ago
  Wow, one more invisible character to worry about that does not get dealt with by a standard `.strip()`
- sctb 8y ago
  These are important things! We've unsullied the title.
dasanman 8y ago
I started writing code (mainly PHP) around 4 years ago. I've never known anything else than composer and package managers in general, and it blows my mind when people dont use them
- colecut 8y ago
  I could be wrong but I thought most people who use PHP today were using it back before composer and PHP namespaces were even a thing.. Unless maybe you're working in Wordpress land, which I'm not sure has really adopted the practice of namespaces. Out of curiosity, what made you choose PHP as a primary language 4 years ago?
throw2016 8y ago
Apparently Wikipedia, Facebook, Slack are not enough to convince some of PHPs credentials. But add a badly designed package manager that replicates all the problems in Ruby and NPM and suddenly PHP is 'interesting' again. This just reflects the warped incentives of a community more interested in hype, resume padding and currying influence in ecosystem with questionable package managers and frameworks than any technical scrutiny. PHP was always simple to setup and use, the system package manager has all the extensions. App deployment was a breeze anyone could do it. On the other hand with Ruby or Node you need a full build environment, compilation and dependency hell just to deploy apps. Yet according according to some its PHP that is 'in the dark ages'. See the warped incentives and user hostile behavior. It difficult to see how this makes PHP better and hopefully it's attempt to 'gain respect' will not take it down the same path.
- tylerjwilk00 8y ago
  Although composer was inspired by npm - they are not identical. Composer always just works for me. But with npm I always end up in some strange dependency hell. Add the fact that JS standard library is lacking in some basic functionality and you end up with a ludicrous amount of dependencies. In short, give composer a try if you are already building apps in PHP.
- lgl 8y ago
  PHP was always simple to setup and use, the system package manager has all the extensions. Sorry if I misunderstood what you're trying to say but this makes no sense to me. It's still the same simplicity to install PHP. But what you do with the package manager is not the same thing as what you achieve with composer. PHP extensions != PHP libraries. You can also use the package manager to install python, ruby, perl, etc. What you generally don't do is use the package manager to install random 3rd party libraries (unless it's a really big project that's been packaged. e.g.: phpmyadmin) Surely you wouldn't want php library maintainers to also create deb's and rpm's of their projects and host their own repositories, deal with distro release politics and other hindrances just so you can use apt or yum to install them?
- paulryanrogers 8y ago
  While PHP core and officially sanctioned extensions have long been bundled in source and binary distributions there has also been PECL and PEAR.
RpFLCL 8y ago
I read through this post and spent the morning reading more about Composer. I've been on the fence for a while, but I'm still not sure yet if this is right for me. Most of the projects I work on have minimal dependncies & existing autoloading strategies. While I would like to have access to new dependencies via Composer it seems like I'll be forced to engage in heavy refactoring to update namespaces and will need to somehow package my existing code. Curious if anyone here has firsthand experience adding Composer to an existing project that wasn't dependency heavy?
- tylerjwilk00 8y ago
  You won't even notice it. Everything you already have will continue to work fine. All you have to do is include the autoloader somewhere in your code path. An example assuming you already installed composer on the machine into your /bin or similar directory. # add a new dependency: composer require guzzlehttp/guzzle # this dependency will now be in the vendor directory ls ./vendor # update your apps entry point (ie: frontcontroller.php): // require composer's autoloader require ('vendor/autoload.php'); # autoload will now find any dependencies you add via composer // create guzzle client $client = new \GuzzleHttp\Client(); # another tip, if you already have a bunch of class files some where (ie: myapp/src/classes , myapp/src/models ) You can include class paths via composer.json "autoload": { "classmap": ["classes/", "models/", "MyClass.php"] } You can now remove any hard-coded include or require statements. There is a lot more things you can do with it but this is the most basic example.
  - krapp 8y ago
    >There is a lot more things you can do with it but this is the most basic example. One useful feature is custom commands[0]. [0]https://getcomposer.org/doc/articles/scripts.md#writing-custom-commands https://getcomposer.org/doc/articles/scripts.md#writing-cust... Also, regarding autoloading, I find that once you get used to the structure of PSR-4, adding files to a PSR-4 namespace[1] and just having autoloading work is incredibly helpful. The only pain point is dealing with namespaces everywhere. [1]https://getcomposer.org/doc/04-schema.md#psr-4 https://getcomposer.org/doc/04-schema.md#psr-4
Optimal_Persona 8y ago
I use PHP Composer, but the fact that its logo is actually a conductor makes me cringe and wonder what else is fundamentally wrong with the product. Close enough for PHP, I guess ;0

The short version: If you're a PHP developer, here's why you should use a package manager instead of downloading zip-files.

pasta 8y ago

After using Composer for some years I think these tips are good to think about: * Use full version numbers for your dependencies. * Include the vendor folder in your VCS. The last one I had to think about a lot but it's a real pain to get an old project working again when dependencies are no longer available. Unfortunately this happens a lot.

stunt 8y ago
You always choose a reliable dependency not something random. I never had similar experience or saw a project doing that. You should only version composer.lock and composer.json files. Ignore vendor directory and leave that job to your build step in CI/CD...
- viraptor 8y ago
  Things disappear, or get deleted, or old versions get replaced for various reasons. There's no "reliable dependency". Even if you think something's reliable, sone deeper dependency may disappear. See npm and left-pad for example. Committing vendor directory may or may not be a good idea. But having your own copy of all dependencies (current and past) is necessary.
  - marenkay 8y ago
    > But having your own copy of all dependencies (current and past) is necessary. Definitely! Git mirrors are cheap, and there are various solutions for composer proxies out there. If you consider CI/CD you will want freedom from external calls anyway.
- mnemnc 8y ago
  That's why we have our own composer repository powered by satis. When set up correctly, it can be used as a "proxy" for packagist, ensuring you always have an installable version of your dependencies, even if they are not available via packagist anymore.
  - dotancohen 8y ago
    Most insightful comment on this thread. I'm looking into satis now, thank you! https://github.com/composer/satis https://github.com/composer/satis
marenkay 8y ago
Major and minor versions usually are sufficient, as you can lock to a specific version anyway. You should never VCS the vendor directory. If you are concerned about disappearing 3rd party dependencies, you should: - have a local cache - keep e.g. git mirrors for 3rd party dependencies - invest a bit more time in selecting dependencies with higher quality. I've seen repos with vendors checked in. A few years, hundreds of thousands of commits, and even a git status takes 30 seconds to run. Just saying, there is a more sensible approach that beats storing vendors in the project :-)
- pjmlp 8y ago
  While sensible advice, usually only the VCS approach works across many organizations, which don't provide the resources to do it in any other more reasonable way.
- deleted 8y ago
  [deleted]
- gkya 8y ago
  Checking your dependencies in is a good idea. When you check out a version from some time ago, you won't have to worry if those versions are still available in your cache or on remotes. Especially if the package manager is not very dependable. Furthermore, if you patch or edit your dependencies, that information is permanently recorded too.
  - sopooneo 8y ago
    At my job we almost never version control our vendor directory, but you have a very strong point, and I am not strongly in our camp. One pain point in particular, is that if you are using Git Bisect to find out where a bug appeared, and you don't have your dependencies version controlled, you either have to run "composer install" at each bisect step, or set up an equivalent checkout hook. And while I guess the checkout hook could work, it is going to make a lot of other work a lot slower.
- roel_v 8y ago
  "and even a git status takes 30 seconds to run" That's a problem with your vcs, not with the (defensive) practice of tracking external dependencies.
fredsted 8y ago
Your build system should take care of this for you. For example, build a docker image or store an artifact (e.g. zip file) of the full build including dependencies. Then put it on your own docker registry or the artifact on S3, for example.
waibelp 8y ago
Instead of including the vendor folder into projects you may use satis [0] to "mirror" all of your dependencies. That means you will not have any broken stuff if packagist is down or any of your dependencies are missing. [0]: https://github.com/composer/satis https://github.com/composer/satis
Seldaek 8y ago
IMO for the first point you should rather use ^x.y with the minimum version you require and then accept new releases as they come. If you do regular updates you should notice quickly when something break and be able to revert that update easily. If you update 20 packages at once it becomes harder to pinpoint where a regression occurred. As for including the vendor dir in your VCS repo, this comes with quite a few drawbacks. That's one of the things Private Packagist (https://packagist.com https://packagist.com) aims to fix though, as it keeps mirrored copies of your dependencies' zip archives so you get more reliable installs.
- Double_a_92 8y ago
  What guarantees you that packagist will be around in e.g. 15 years when you would like to start some old project?
  - Seldaek 8y ago
    If you are talking about such long time frames, then indeed archiving a project with its vendor directory might be a good idea once you decide to relegate it to the freezer.
    - Piskvorrr 8y ago
      How about "vendor decided to migrate off Github last week, and managed to break all their tags in the process"? (Not that this would have actually happened to me this Monday, noooo ;)) Long timeframes are not the only issue with external dependencies...
  - krapp 8y ago
    You don't need (and shouldn't depend on) packagist when using Composer. You can import packages directly from Github, Bitbucket, etc., or even locally, you just have to write a bit more JSON.
    - mrrsm 8y ago
      What do you suggest when the package you are using is pulling in other packages from packagist?
hrktb 8y ago
> * Use full version numbers for your dependencies. The tradeoff for this approach is to have to resolve version conflicts manually anytime there is more than minor dependency changes. In particular, adding a package that is newer than most of your dependencies can be a nightmare when you locked down all the working revisions of your libraries. On one hand there is less drama about packages changing under one's feet, on the other hand part of composer's job is shifted back to the dev who does the package updates. Personally I would advise a more balanced approach of allowing minor version changes and only block major ones.

dvfjsdhgfv 8y ago

So I just wanted to try Laravel Factory. I was likely to buy it as I tried some Laravel CRUD builders in the past and each had some flaws that your project seems not to have. However, I couldn't complete registration as you don't allow disable throwaway domains. I just wanted to let you know it makes no sense whatsoever. I never disclose my real e-mail addresses at that stage. Just wanted to let you know - and also others who make the same mistake. If you don't want my money, that's OK.

welly 8y ago
Just tested it myself with guerillamail and mailinator. And as you say, "Disposable email addresses are not allowed". I get why they'd do this because obviously they want to capture potential buyers of their software to pester at a later date to buy but I'm not a potential buyer until I've tried it. So I'm another one that won't be handing over any money.
danieltillett 8y ago
It is quite possible that they have found that people who use disposable email accounts never buy anything. My company also blocks disposable email address because we found that people using them were just abusing our service and our sales went up after doing so. The funny thing is apart from emailing the free code we almost never contact anyone since we know 99% of our free users are not potential paying customers and so there is no point wasting our time on them. We only know this because they give us their real email address which allows us to screen them out.
- dvfjsdhgfv 8y ago
  Maybe for some services that you can abuse blocking disposable addresses might make sense, but not for this one. In any case, I finally decided to register using a throwaway spambox from Gmail instead of Mailinator (what difference does it make, really...) and it turns out the Laravel Factory is inferior to Voyager as it doesn't support roles out of the box. Which is a pity as other things have been solved quite nicely. I'll give it a try in a few months, maybe they catch up.

chx 8y ago

The fundamental problem with composer is it goes and updates everything even when I just want it to deal with a single package. And then, of course, because so many packages promise but can't keep proper semver, things break. Marvelous. Coupled with arcane version syntax (Drupal's version system predates Composer and it used natural syntax like foo (>=2.1.1) bar (2.x) so all they needed to do is to take the about 30 lines of well commented code, no need to memorize a list of sigils but no), excruciating slowness makes me wish I never heard of it much less need to work with it daily.

Seldaek 8y ago
Updating single packages is very much possible, see https://getcomposer.org/doc/03-cli.md#update https://getcomposer.org/doc/03-cli.md#update - as for semver promises, that's really up to you and which packages you decide to trust, nothing the tool can do about it.
- chx 8y ago
  Note I said "deal with", it's not update, I learned long ago never to touch composer update. I think it is require that does this. Or that install doesn't have a single package argument? Whatever. I am not alone in finding the only way to actually use composer is to nail down every single package to a single version. Do note I didn't write https://github.com/webflo/drupal-core-strict https://github.com/webflo/drupal-core-strict which is just that https://github.com/webflo/drupal-core-strict/blob/8.5.4/composer.json https://github.com/webflo/drupal-core-strict/blob/8.5.4/comp... As for trust, noone in the PHP world! Absolutely noone! I got into a debate with Rasmus about the meaning of backwards compatibility around the time PHP 5.4 began to throw additional warnings (not a new class of errors which could be additionally displayed, no) on code that previously worked. Drupal 8.4 released with a known bug that caused some code to merrily lose files uploaded by users because of a BC break. If you want BC, look at the kernel Linux API and even the ABI.
  - jtreminio 8y ago
    > Or that install doesn't have a single package argument? `composer require {vendor}/{your-amazing-package}:{version}`

joemaller1 8y ago

The Composer project and Packagist are the catalysts which made it possible to drag PHP development out of the dark ages, but it's still got some rough edges that will eat a afternoon. Recent example: Re-organizing namespaces and classes in an internal library. Losing my mind (doing everything right) until finally realizing Composer wasn't updating the autoloader to reflect changes to the lib's composer.json. For something that works really well when it’s working, I have blown a lot of hours fighting with this stuff.

steve_adams_86 8y ago
Rebuilding the autoloader became a normal step in diagnosing issues for me. You never know... These days I deal with npm which in some ways is nicer yet it can still eat afternoons.
- mkirklions 8y ago
  So far no issues with PHP other than the occasional turn it off and back on again. NPM? Wake up on a saturday morning and hot reload + react tools no longer works? F me. On the bright side I almost finished the front end, so I can casually mess around with the solution every few days as I do my daily work in laravel.
  - steve_adams_86 8y ago
    Haha, fair enough. The other day I was getting this bizarre mismatch of versions of a dependency and I couldn't figure out how it could even matter. Like, who cares if they're two minor versions apart? Neither of them were global so there was no conflict for their parent modules. _That_ is the kind of stuff that kills me about npm. It can be really reeeaally hard to figure out what to do in those situations. Also, package.json is arguably a pretty gnarly way to organize... Well, everything? It's the kitchen sink of configuration, but it's supposed to be for managing packages. But no, you can also configure your packages in there, configure scripts for your application, etc. It's nuts. Even so, both of them are miles ahead of what we had 10 years ago!
8y ago

NickHoff 8y ago

There's a zero-width-joiner and then a space at the start of this title. It's &zwj; What, Why and How of PHP Composer The zwj doesn't print (of course) but the space does, causing the alignment of titles on the front page to be slightly off. It tweaked me. Always looking out for the important things...

severine 8y ago
And it won't show in our history...
Operyl 8y ago
This is the only reason I decided to click into the comments, even.
danso 8y ago
Wow, one more invisible character to worry about that does not get dealt with by a standard `.strip()`
sctb 8y ago
These are important things! We've unsullied the title.

dasanman 8y ago

I started writing code (mainly PHP) around 4 years ago. I've never known anything else than composer and package managers in general, and it blows my mind when people dont use them

colecut 8y ago
I could be wrong but I thought most people who use PHP today were using it back before composer and PHP namespaces were even a thing.. Unless maybe you're working in Wordpress land, which I'm not sure has really adopted the practice of namespaces. Out of curiosity, what made you choose PHP as a primary language 4 years ago?

throw2016 8y ago

Apparently Wikipedia, Facebook, Slack are not enough to convince some of PHPs credentials. But add a badly designed package manager that replicates all the problems in Ruby and NPM and suddenly PHP is 'interesting' again. This just reflects the warped incentives of a community more interested in hype, resume padding and currying influence in ecosystem with questionable package managers and frameworks than any technical scrutiny. PHP was always simple to setup and use, the system package manager has all the extensions. App deployment was a breeze anyone could do it. On the other hand with Ruby or Node you need a full build environment, compilation and dependency hell just to deploy apps. Yet according according to some its PHP that is 'in the dark ages'. See the warped incentives and user hostile behavior. It difficult to see how this makes PHP better and hopefully it's attempt to 'gain respect' will not take it down the same path.

tylerjwilk00 8y ago
Although composer was inspired by npm - they are not identical. Composer always just works for me. But with npm I always end up in some strange dependency hell. Add the fact that JS standard library is lacking in some basic functionality and you end up with a ludicrous amount of dependencies. In short, give composer a try if you are already building apps in PHP.
lgl 8y ago
PHP was always simple to setup and use, the system package manager has all the extensions. Sorry if I misunderstood what you're trying to say but this makes no sense to me. It's still the same simplicity to install PHP. But what you do with the package manager is not the same thing as what you achieve with composer. PHP extensions != PHP libraries. You can also use the package manager to install python, ruby, perl, etc. What you generally don't do is use the package manager to install random 3rd party libraries (unless it's a really big project that's been packaged. e.g.: phpmyadmin) Surely you wouldn't want php library maintainers to also create deb's and rpm's of their projects and host their own repositories, deal with distro release politics and other hindrances just so you can use apt or yum to install them?
paulryanrogers 8y ago
While PHP core and officially sanctioned extensions have long been bundled in source and binary distributions there has also been PECL and PEAR.

RpFLCL 8y ago

I read through this post and spent the morning reading more about Composer. I've been on the fence for a while, but I'm still not sure yet if this is right for me. Most of the projects I work on have minimal dependncies & existing autoloading strategies. While I would like to have access to new dependencies via Composer it seems like I'll be forced to engage in heavy refactoring to update namespaces and will need to somehow package my existing code. Curious if anyone here has firsthand experience adding Composer to an existing project that wasn't dependency heavy?

tylerjwilk00 8y ago
You won't even notice it. Everything you already have will continue to work fine. All you have to do is include the autoloader somewhere in your code path. An example assuming you already installed composer on the machine into your /bin or similar directory. # add a new dependency: composer require guzzlehttp/guzzle # this dependency will now be in the vendor directory ls ./vendor # update your apps entry point (ie: frontcontroller.php): // require composer's autoloader require ('vendor/autoload.php'); # autoload will now find any dependencies you add via composer // create guzzle client $client = new \GuzzleHttp\Client(); # another tip, if you already have a bunch of class files some where (ie: myapp/src/classes , myapp/src/models ) You can include class paths via composer.json "autoload": { "classmap": ["classes/", "models/", "MyClass.php"] } You can now remove any hard-coded include or require statements. There is a lot more things you can do with it but this is the most basic example.
- krapp 8y ago
  >There is a lot more things you can do with it but this is the most basic example. One useful feature is custom commands[0]. [0]https://getcomposer.org/doc/articles/scripts.md#writing-custom-commands https://getcomposer.org/doc/articles/scripts.md#writing-cust... Also, regarding autoloading, I find that once you get used to the structure of PSR-4, adding files to a PSR-4 namespace[1] and just having autoloading work is incredibly helpful. The only pain point is dealing with namespaces everywhere. [1]https://getcomposer.org/doc/04-schema.md#psr-4 https://getcomposer.org/doc/04-schema.md#psr-4

Optimal_Persona 8y ago

I use PHP Composer, but the fact that its logo is actually a conductor makes me cringe and wonder what else is fundamentally wrong with the product. Close enough for PHP, I guess ;0