Hacker News Reader

Comment by joemaller1 | Hacker News Reader

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.

View on HN

In the future, if/when you change your namespaces or add new Class files, just run:

`composer dump-autoload`

This will dump the autoloader and rebuild it. This is much much faster than an entire `composer install` run. For additional usage options try:

`composer help dump-autoload`

* Unrelated: HN can we please get better markdown?

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.

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

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

If you wish to daemonize it have a file change listener run it when it observes file system changes in the appropriate directory. If that is too much work a quick hack would be:

    watch -n 10 composer dumpautoloaf --no-scripts &

Full disclosure: I did not verify this command would work well

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.

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.

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!

Phpstorm is a good investment.

Sounds interesting, how does it help with Composer?

If you rename a class through PHPStorm, it will go through the entire codebase, find the old name and update it, including in the autoloaded class maps and files.

Reply on news.ycombinator.com