
What, why and how of PHP Composer - laravelfactory
https://laravelfactory.com/blog/php-composer-tutorial
======
joemaller1
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.

~~~
jtreminio
It generates a map file when you run `composer install` and many of the
several other commands.

Yours is not really a critique of composer, since it's not a daemon or a
continuously run script. You run it once and done.

~~~
workinthehead
No, it is though, because other package managers are not daemons and they
don't have this problem.

~~~
sieabahlpark
Composer is optimized for how php executes which is once per request. If you
want to compute namespaces per request that's your choice.

------
sshine
The short version:

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

------
throw2016
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.

~~~
lgl
_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?

------
dasanman
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
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?

------
pasta
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.

~~~
marenkay
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 :-)

~~~
gkya
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
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.

------
dvfjsdhgfv
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.

~~~
danieltillett
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
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.

~~~
danieltillett
It is rather silly to block disposable addresses if you are going to allow
free email services like gmail.

In our case we block all free and disposable email address since nobody
without a corporate or university email address uses our service (it is aimed
at scientists).

We used to let anyone use the service for free without registering for small
scale use, but what we found were some commercial suppliers (our target
market) were just telling their customers to use our free service rather than
fork out the $0.02 it would have cost them to buy a license on assays they
were selling for $10. Once cutoff from the ability to freeload, quite a number
of these commercial suppliers decided to buy a license from us.

The good thing about this is not only did we get the business, but their
customers got the benefit of our service automatically.

------
RpFLCL
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
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
>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-
cust...](https://getcomposer.org/doc/articles/scripts.md#writing-custom-
commands)

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
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

------
NickHoff
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...

~~~
Operyl
This is the only reason I decided to click into the comments, even.

------
chx
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
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
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/comp...](https://github.com/webflo/drupal-core-
strict/blob/8.5.4/composer.json)

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
> Or that install doesn't have a single package argument?

`composer require {vendor}/{your-amazing-package}:{version}`

